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. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
