Re: Add WAL read stats to pg_stat_wal

On Mon, Feb 20, 2023 at 10:51 AM Kyotaro Horiguchi
<horikyota(dot)ntt(at)gmail(dot)com> wrote:
>
> At Thu, 16 Feb 2023 11:11:38 -0800, Andres Freund <andres(at)anarazel(dot)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