Horton

Re: CHECKPOINT unlogged data

Christoph Berg <myon@debian.org>

View thread
From: Christoph Berg <myon@debian.org>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Fujii Masao <masao.fujii@oss.nttdata.com>, Andres Freund <andres@anarazel.de>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-06-06T16:20:21Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add FLUSH_UNLOGGED option to CHECKPOINT command.

  2. Add MODE option to CHECKPOINT command.

  3. Add option list to CHECKPOINT command.

  4. Rename CHECKPOINT_FLUSH_ALL to CHECKPOINT_FLUSH_UNLOGGED.

  5. Rename CHECKPOINT_IMMEDIATE to CHECKPOINT_FAST.

Re: Nathan Bossart
> I imagine the documentation will pretty clearly indicate that setting WAIT
> to "false" will cause CHECKPOINT to not wait for it to finish.

I can add it, it's easy enough...

> I don't understand why we need to add both FAST and IMMEDIATE.

We have both:

=# checkpoint ;
2025-06-06 18:09:25.743 CEST [872379] LOG:  checkpoint starting: immediate force wait

pg_basebackup --checkpoint=fast

Could we settle for one official name for that? Then we could use that
name in all contexts.

> > +    <term><literal>FLUSH_ALL</literal></term>
> 
> Could we rename this to something like FLUSH_UNLOGGED or INCLUDE_UNLOGGED?
> IMHO that's more descriptive.

That's again coming from what the log message is saying:

=# checkpoint (flush_all);
2025-06-06 18:12:46.298 CEST [873436] LOG:  checkpoint starting: immediate force wait flush-all

I think we should be consistent there.

#define CHECKPOINT_FLUSH_ALL    0x0010  /* Flush all pages, including those
                                         * belonging to unlogged tables */

Maybe CHECKPOINT_FLUSH_UNLOGGED would be more explicit?

> My attempt at this patch back in 2020 included the following note, which
> seems relevant here:
> 
> +   Note that the server may consolidate concurrently requested checkpoints or
> +   restartpoints.  Such consolidated requests will contain a combined set of
> +   options.  For example, if one session requested an immediate checkpoint and
> +   another session requested a non-immediate checkpoint, the server may combine
> +   these requests and perform one immediate checkpoint.

The CHECKPOINT documentation links to `28.5. WAL Configuration`,
should this be mentioned there instead?

> We might also want to make sure it's clear that CHECKPOINT does nothing if
> there's been no database activity since the last one (or, in the case of a
> restartpoint, if there hasn't been a checkpoint record).

That's taken care of by "force":

#define CHECKPOINT_FORCE        0x0008  /* Force even if no activity */

Christoph