Re: Is there a way (except from server logs) to know the kind of on-going/last checkpoint?

From: Justin Pryzby <pryzby(at)telsasoft(dot)com>
To: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
Cc: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Melanie Plageman <melanieplageman(at)gmail(dot)com>
Subject: Re: Is there a way (except from server logs) to know the kind of on-going/last checkpoint?
Date: 2021-12-07 22:37:04
Message-ID: 20211207223704.GZ17618@telsasoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Dec 07, 2021 at 11:18:37PM +0100, Tomas Vondra wrote:
> On 12/7/21 15:36, Bharath Rupireddy wrote:
> > Currently one can know the kind of on-going/last checkpoint (shutdown,
> > end-of-recovery, immediate, force etc.) only via server logs that to
> > when log_checkpoints GUC is on.

> > The checkpoint info can be obtained from the control file (either by
> > pg_control_checkpoint() or by pg_controldata tool) whereas checkpoint kind
> > isn't available there.

> > How about we add an extra string field to the control file alongside
> > the other checkpoint info it already has? This way, the existing
> > pg_control_checkpoint() or pg_controldata tool can easily be enhanced
> > to show the checkpoint kind as well. One concern is that we don't want
> > to increase the size of pg_controldata by more than the typical block
> > size (of 8K) to avoid any torn-writes. With this change, we might add
> > at max the strings specified at [1]. Adding it to the control file has
> > an advantage of preserving the last checkpoint kind which might be
> > useful.

> > [1] for checkpoint: "checkpoint shutdown end-of-recovery immediate
> > force wait wal time flush-all"
> > for restartpoint: "restartpoint shutdown end-of-recovery immediate
> > force wait wal time flush-all"
>
> I'd bet squashing all of this into a single string (not really a flag)
> will just mean people will have to parse it, etc. Keeping individual
> boolean flags (or even separate string fields) would be better, I guess.

Since the size of controldata is a concern, I suggest to add an int16 to
populate with flags, which pg_controldata can parse for display.

Note that this other patch intends to add the timestamp and LSN of most recent
recovery to controldata.
https://commitfest.postgresql.org/36/3183/

> We already have some checkpoint info in pg_stat_bgwriter, but that's
> just aggregated data, not very convenient for info about the current
> checkpoint. So maybe we should add pg_stat_progress_checkpoint, showing
> various info about the current checkpoint?

It could go into the pg_stat_checkpointer view, which would be the culmination
of another patch (cc Melanie).
https://commitfest.postgresql.org/36/3272/

--
Justin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bossart, Nathan 2021-12-07 22:47:18 Re: Should we improve "PID XXXX is not a PostgreSQL server process" warning for pg_terminate_backend(<<postmaster_pid>>)?
Previous Message Tomas Vondra 2021-12-07 22:18:37 Re: Is there a way (except from server logs) to know the kind of on-going/last checkpoint?