On Mon, May 10, 2021 at 10:25 PM Amul Sul <sulamul@gmail.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?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com