Date: Sat, 26 Feb 2022 00:35:45 +0800
From: Julien Rouhaud <rjuju123@gmail.com>
To: Nitin Jadhav <nitinjadhavpostgres@gmail.com>
Cc: Matthias van de Meent <boekewurm+postgres@gmail.com>,
	Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>,
	Bruce Momjian <bruce@momjian.us>, Tom Lane <tgl@sss.pgh.pa.us>,
	Magnus Hagander <magnus@hagander.net>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Report checkpoint progress with pg_stat_progress_checkpoint
 (was: Report checkpoint progress in server logs)
Message-ID: <20220225163545.slsxurx2wbpme7vg@jrouhaud>
References: <CAMm1aWbjzP9g9ebkYqqJvNAW4jh6wP0maKW2Ozcv8PLVu76cFA@mail.gmail.com>
 <20220218074351.wgfosjt5lql2vjbr@jrouhaud>
 <CAMm1aWadyUhb89DEfgrs2j5i2u--O06x6oTp0EEhgGHtnw-SXA@mail.gmail.com>
 <20220219053215.r4wqatln5awklecf@jrouhaud>
 <CAMm1aWZzPVpLs7k5sQU4DObvh6YpOhjibcq2ykDrC_n25jeJNA@mail.gmail.com>
 <CAMm1aWZ07VYUPpvmV9Ck_VX-o+xH=hEBs-67scd_Us6U6FKbHA@mail.gmail.com>
 <CAEze2WhXEU+n=o0UjQSx8sJ3Bf7Ru3NN+t5Jzrbt9pFfDrLy0A@mail.gmail.com>
 <CAMm1aWaL8S9AbeLQrSGNBW+d3165dmV=JnCfVyjo9UGKCz4vHg@mail.gmail.com>
 <20220225070352.fhfwnl5ksfsa4eew@jrouhaud>
 <CAMm1aWZPb5pGYLVXz5TkApbSERozmJd+n72jDMG=Pv5HVh_n4g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAMm1aWZPb5pGYLVXz5TkApbSERozmJd+n72jDMG=Pv5HVh_n4g@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/20220225163545.slsxurx2wbpme7vg%40jrouhaud>
Precedence: bulk

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.