On Wed, Mar 3, 2021 at 7:56 PM Dilip Kumar <dilipbal...@gmail.com> wrote: > > On Wed, Mar 3, 2021 at 4:50 PM Amul Sul <sula...@gmail.com> wrote: > > > > On Wed, Mar 3, 2021 at 12:08 PM Dilip Kumar <dilipbal...@gmail.com> wrote: > > > > > Yes, it is possible to allow wal temporarily for itself by setting > > LocalXLogInsertAllowed, but when we request Checkpointer for the > > end-of-recovery > > checkpoint, the first thing it will do is that wal prohibit state transition > > then recovery-end-checkpoint. > > > > Also, allowing WAL write in read-only (WAL prohibited state) mode is against > > this feature principle. > > So IIUC before the checkpoint change the state in the control file we > anyway inform other backend and then they are allowed to write the WAL > is the right? If that is true then what is the problem in first doing > the pending post-recovery process and then informing the backend about > the state change. I mean we are in a process of changing the state to > read-write so why it is necessary to inform all the backend before we > can write WAL? Are we afraid that after we write the WAL and if there > is some failure before we make the system read-write then it will > break the principle of the feature, I mean eventually system will stay > read-only but we wrote the WAL? If so then currently, are we assuring > that once we inform the backend and backend are allowed to write the > WAL there are no chances of failure and the system state is guaranteed > to be changed. If all that is true then I will take my point back. >
The wal prohibit state transition handling code is integrated into various places of the checkpointer process so that it can pick state changes as soon as possible. Before informing other backends we can do UpdateFullPageWrites() but when we try to next the end-of-recovery checkpoint write operation, the Checkpointer will hit ProcessWALProhibitStateChangeRequest() first which will try for the wal prohibit transition state completion and then write the checkpoint record. Regards, Amul
