From: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
---|---|
To: | Nitin Jadhav <nitinjadhavpostgres(at)gmail(dot)com> |
Cc: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Report checkpoint progress with pg_stat_progress_checkpoint (was: Report checkpoint progress in server logs) |
Date: | 2022-02-25 16:35:45 |
Message-ID: | 20220225163545.slsxurx2wbpme7vg@jrouhaud |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Feb 25, 2022 at 08:53:50PM +0530, Nitin Jadhav wrote:
> >
> > I'm not sure what Matthias meant, but as far as I know there's no fundamental
> > difference between checkpoint with and without the CHECKPOINT_IMMEDIATE flag,
> > and there's also no scheduling for multiple checkpoints.
> >
> > Yes, the flags will remain the same but checkpoint.c will test both the passed
> > flags and the shmem flags to see whether a delay should be added or not, which
> > is the only difference in checkpoint processing for this flag. See the call to
> > ImmediateCheckpointRequested() which will look at the value in shmem:
> >
> > /*
> > * Perform the usual duties and take a nap, unless we're behind schedule,
> > * in which case we just try to catch up as quickly as possible.
> > */
> > if (!(flags & CHECKPOINT_IMMEDIATE) &&
> > !ShutdownRequestPending &&
> > !ImmediateCheckpointRequested() &&
> > IsCheckpointOnSchedule(progress))
>
> I understand that the checkpointer considers flags as well as the
> shmem flags and if CHECKPOINT_IMMEDIATE flag is set, it affects the
> current checkpoint operation (No further delay) but does not change
> the current flag value. Should we display this change in the kind
> field of the view or not? Please share your thoughts.
I think the fields should be added. It's good to know that a checkpoint was
trigger due to normal activity and should be spreaded, and then something
upgraded it to an immediate checkpoint. If you're desperately waiting for the
end of a checkpoint for some reason and ask for an immediate checkpoint, you'll
certainly be happy to see that the checkpointer is aware of it.
But maybe I missed something in the code, so let's wait for Matthias input
about it.
From | Date | Subject | |
---|---|---|---|
Next Message | Jacob Champion | 2022-02-25 16:38:22 | Re: Readd use of TAP subtests |
Previous Message | Jacob Champion | 2022-02-25 16:35:39 | Re: Readd use of TAP subtests |