From: Christoph Berg <myon@debian.org>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: CHECKPOINT unlogged data
Date: Fri, 6 Jun 2025 18:20:21 +0200
Message-ID: <aEMVRbmqqg-aaxAN@msg.df7cb.de> (raw)
In-Reply-To: <aEMIrLUDOKgmE_0P@nathan>
References: <aDnaKTEf-0dLiEfz@msg.df7cb.de>
<vp4cewuyo2cw4fk5sxjaovllhe3dscixxo2utu3cgqhzydrqec@wc2nhgx4khpk>
<aDnl5N1u7UBYVaSt@nathan>
<aDnpeJ99HhoMgJ40@msg.df7cb.de>
<7x6gsmev36zzh6lfzydkddbhpnxqgu2k2l2ci2k6foxhrstvj2@bn55g54wjrl4>
<aEK88AwaYBNK1p-O@msg.df7cb.de>
<fc1ed66f-e95a-4d10-a4f7-7fa4bb9a7084@oss.nttdata.com>
<aEL6sDr9RxdSkPm-@msg.df7cb.de>
<aEMIrLUDOKgmE_0P@nathan>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: myon@debian.org, nathandbossart@gmail.com, masao.fujii@oss.nttdata.com, andres@anarazel.de, pgsql-hackers@lists.postgresql.org
Subject: Re: CHECKPOINT unlogged data
In-Reply-To: <aEMVRbmqqg-aaxAN@msg.df7cb.de>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox