Re: Deduplicate code updating ControleFile's DBState.

From: "Bossart, Nathan" <bossartn(at)amazon(dot)com>
To: Amul Sul <sulamul(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Deduplicate code updating ControleFile's DBState.
Date: 2021-09-15 22:49:39
Message-ID: 455E42BB-5E1D-432F-8515-998F8FC3BA1B@amazon.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 9/15/21, 4:47 AM, "Amul Sul" <sulamul(at)gmail(dot)com> wrote:
> On Wed, Sep 15, 2021 at 12:52 AM Bossart, Nathan <bossartn(at)amazon(dot)com> wrote:
>> It looks like ebdf5bf intentionally made sure that we hold
>> ControlFileLock while updating SharedRecoveryInProgress (now
>> SharedRecoveryState after 4e87c48). The thread for this change [0]
>> has some additional details.
>>
>
> Yeah, I saw that and ebdf5bf main intention was to minimize the gap
> between both of them which was quite big previously. The comments
> added by the same commit also describe the case that backends can
> write WAL and the control file is still referring not in
> DB_IN_PRODUCTION and IIUC, which seems to be acceptable.
> Then the question is what would be wrong if a process can see an
> inconsistent shared memory view for a small window? Might be
> wait-promoting might behave unexpectedly, that I have to test.

For your proposed change, I would either leave out this particular
call site or add a "WithLock" version of the function.

void
SetControlFileDBState(DBState state)
{
LWLockAcquire(ControlFileLock, LW_EXCLUSIVE);
SetControlFileDBStateWithLock(state);
LWLockRelease(ControlFileLock);
}

void
SetControlFileDBStateWithLock(DBState state)
{
Assert(LWLockHeldByMeInMode(ControlFileLock, LW_EXCLUSIVE));

ControlFile->state = state;
ControlFile->time = (pg_time_t) time(NULL);
UpdateControlFile();
}

>> As far as the patch goes, I'm not sure why SetControlFileDBState()
>> needs to be exported, and TBH I don't know if this change is really a
>> worthwhile improvement. ISTM the main benefit is that it could help
>> avoid cases where we update the state but not the time. However,
>> there's still nothing preventing that, and I don't get the idea that
>> it was really a big problem to begin with.
>>
>
> Oh ok, I was working on a different patch[1] where I want to call this
> function from checkpointer, but I agree exporting function is not in
> the scope of this patch.

Ah, I was missing this context. Perhaps this should be included in
the patch set for the other thread, especially if it will need to be
exported.

Nathan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jaime Casanova 2021-09-15 23:09:59 right join with partitioned table crash
Previous Message Bossart, Nathan 2021-09-15 22:31:20 Re: Estimating HugePages Requirements?