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
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? |