Hi Amul, On Tue, Jun 16, 2020 at 6:56 AM amul sul <sula...@gmail.com> wrote: > The proposed feature is built atop of super barrier mechanism commit[1] to > coordinate > global state changes to all active backends. Backends which executed > ALTER SYSTEM READ { ONLY | WRITE } command places request to checkpointer > process to change the requested WAL read/write state aka WAL prohibited and > WAL > permitted state respectively. When the checkpointer process sees the WAL > prohibit > state change request, it emits a global barrier and waits until all > backends that > participate in the ProcSignal absorbs it.
Why should the checkpointer have the responsibility of setting the state of the system to read-only? Maybe this should be the postmaster's responsibility - the checkpointer should just handle requests to checkpoint. I think the backend requesting the read-only transition should signal the postmaster, which in turn, will take on the aforesaid responsibilities. The postmaster, could also additionally request a checkpoint, using RequestCheckpoint() (if we want to support the read-onlyness discussed in [1]). checkpointer.c should not be touched by this feature. Following on, any condition variable used by the backend to wait for the ALTER SYSTEM command to finish (the patch uses CheckpointerShmem->readonly_cv), could be housed in ProcGlobal. Regards, Soumyadeep (VMware) [1] https://www.postgresql.org/message-id/CAE-ML%2B-zdWODAyWNs_Eu-siPxp_3PGbPkiSg%3DtoLeW9iS_eioA%40mail.gmail.com