On Mon, Feb 20, 2023 at 10:51 AM Kyotaro Horiguchi <horikyota....@gmail.com> wrote: > > At Thu, 16 Feb 2023 11:11:38 -0800, Andres Freund <and...@anarazel.de> wrote > in > > I wonder if we should keep the checkpointer around for longer. If we have > > checkpointer signal postmaster after it wrote the shutdown checkpoint, > > postmaster could signal walsenders to shut down, and checkpointer could do > > some final work, like writing out the stats. > > I suspect this could be useful for other things as well. It's awkward that > > we > > don't have a place to put "just before shutting down" type tasks. And > > checkpointer seems well suited for that. > > I totally agree that it will be useful, but I'm not quite sure how > checkpointer would be able to let postmaster know about that state > without requiring access to shared memory.
The checkpointer can either set a flag in shared memory (CheckpointerShmem or XLogCtl) or send a multiplexed SIGUSR1 (of course, this one too needs shared memory access for PMSignalState) or SIGUSR2 (pqsignal(SIGUSR2, dummy_handler); /* unused, reserve for children */) if we don't want shared memory access after it writes a shutdown checkpoint. Having said that, what's the problem if we use shared memory to report the shutdown checkpoint to the postmaster? In case of abnormal shutdown where shared memory gets corrupted, we don't even write a shutdown checkpoint, no? In such a case, the postmaster doesn't send SIGUSR2 to the checkpointer, instead it sends SIGQUIT. AFICS, using shared memory doesn't seem to have any problem. Do you have any other thoughts in mind? -- Bharath Rupireddy PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
