Re: [Patch] ALTER SYSTEM READ ONLY

On Tue, May 11, 2021 at 11:33 AM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> On Mon, May 10, 2021 at 10:25 PM Amul Sul <sulamul(at)gmail(dot)com> wrote:
> >
> > Yes, we don't want any write slip in before UpdateFullPageWrites().
> > Recently[1], we have decided to let the Checkpointed process call
> > XLogAcceptWrites() unconditionally.
> >
> > Here problem is that when a backend executes the
> > pg_prohibit_wal(false) function to make the system read-write, the wal
> > prohibited state is set to inprogress(ie.
> > WALPROHIBIT_STATE_GOING_READ_WRITE) and then Checkpointer is signaled.
> > Next, Checkpointer will convey this system change to all existing
> > backends using a global barrier, and after that final wal prohibited
> > state is set to the read-write(i.e. WALPROHIBIT_STATE_READ_WRITE).
> > While Checkpointer is in the progress of conveying this global
> > barrier, any new backend can connect at that time and can write a new
> > record because the inprogress read-write state is equivalent to the
> > final read-write state iff LocalXLogInsertAllowed != 0 for that
> > backend. And, that new record could slip in before or in between
> > records to be written by XLogAcceptWrites().
> >
> > 1] http://postgr.es/m/CA+TgmoZYQN=rcYE-iXWnjdvMAoH+7Jaqsif3U2k8xqXipBaS7A@mail.gmail.com
>
> But, IIUC, once the state is set to WALPROHIBIT_STATE_GOING_READ_WRITE
> and signaled to the checkpointer. The checkpointer should first call
> XLogAcceptWrites and then it should inform other backends through the
> global barrier? Are we worried that if we have written the WAL in
> XLogAcceptWrites but later if we could not set the state to
> WALPROHIBIT_STATE_READ_WRITE? Then maybe we can inform all the
> backend first but before setting the state to
> WALPROHIBIT_STATE_READ_WRITE, we can call XLogAcceptWrites?
>

I get why you think that, I wasn't very precise in briefing the problem.

Any new backend that gets connected right after the shared memory
state changes to WALPROHIBIT_STATE_GOING_READ_WRITE will be by
default allowed to do the WAL writes. Such backends can perform write
operation before the checkpointer does the XLogAcceptWrites(). Also,
possible that a backend could connect at the same time checkpointer
performing XLogAcceptWrites() and can write a wal.

So, having XLogAcceptWrites() before does not really solve my concern.
Note that the previous patch XLogAcceptWrites() does get called before
global barrier emission.

Please let me know if it is not yet cleared to you, thanks.

Regards,
Amul