Re: [Patch] ALTER SYSTEM READ ONLY
Amul Sul <sulamul@gmail.com>
On Wed, Mar 3, 2021 at 12:08 PM Dilip Kumar <dilipbalaut@gmail.com> wrote: > > On Tue, Mar 2, 2021 at 9:01 PM Dilip Kumar <dilipbalaut@gmail.com> wrote: > > > > > > > We don't want that to happen in cases where previous recovery-end-checkpoint is > > > skipped in startup. We want Checkpointer first to convey the barrier to all > > > backends but, the backend shouldn't write wal until the Checkpointer writes > > > recovery-end-checkpoint record. > > > > > > To refrain these backends from writing WAL I think we should keep the server in > > > crash recovery mode until UpdateFullPageWrites(), > > > end-of-recovery-checkpoint, and XLogReportParameters() are performed. > > I did not read the code for this, but let me ask something about this > case. Why do we want checkpointer to convey the barrier to all the > backend before completing the end of recovery checkpoint and other > stuff? Is it because the system is still in WAL prohibited state? Consider the previous case, where the user wants to change the system to read-write. When a permitted user executes pg_prohibit_wal(false), the wal prohibited state in shared memory updated to GOING_READ_WRITE which is the transition state and then waits until the transition state completes and the final state (i.e. READ_WRITE) gets updated in shared memory. To set the final set is a job of the Checkpointer process. We have integrated code into the Checkpointer process such that if it sees wal prohibit transition state then it completes that as soon as possible by doing necessary steps i.e. emitting super barriers, then update the final wal prohibited state in shared memory and in control file. > Is > it possible that as soon as we get the pg_prohibit_wal(false) request > the receiving backend start allowing the WAL writing for itself and > finish the all post-recovery pending work and then inform the > checkpointer to inform all other backends? > 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. Regards, Amul
Commits
-
Initialize variable to placate compiler.
- a030a0c5ccb1 15.0 landed
-
StartupXLOG: Don't repeatedly disable/enable local xlog insertion.
- 18e0913a4203 15.0 landed
-
StartupXLOG: Call CleanupAfterArchiveRecovery after XLogReportParameters.
- a75dbf7f9ee6 15.0 landed
-
Postpone some end-of-recovery operations related to allowing WAL.
- 811051c2e7af 15.0 landed
-
Refactor some end-of-recovery code out of StartupXLOG().
- 6df1543abfed 15.0 landed
-
Re-enable contrib/bloom's TAP tests.
- 7d1aa6bf1c27 15.0 cited
-
Remove unnecessary call to ReadCheckpointRecord().
- 1d919de5eb3f 15.0 cited
-
Allow for error or refusal while absorbing a ProcSignalBarrier.
- a3ed4d1efe9f 14.0 landed
-
Add comment to explain an unused function parameter
- 101f903e51f5 14.0 cited
-
Extend the ProcSignal mechanism to support barriers.
- 16a4e4aecd47 13.0 cited
-
At promotion, don't leave behind a partial segment on the old timeline.
- 7cbee7c0a1db 9.5.0 cited