Date: Fri, 6 Jun 2025 10:26:36 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: Christoph Berg <myon@debian.org>
Cc: Fujii Masao <masao.fujii@oss.nttdata.com>,
	Andres Freund <andres@anarazel.de>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: CHECKPOINT unlogged data
Message-ID: <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <aEL6sDr9RxdSkPm-@msg.df7cb.de>
Archived-At: <https://www.postgresql.org/message-id/aEMIrLUDOKgmE_0P%40nathan>
Precedence: bulk

On Fri, Jun 06, 2025 at 04:26:56PM +0200, Christoph Berg wrote:
> Re: Fujii Masao
>> Some users might want to trigger a spread checkpoint but not wait for
>> it to finish, since it could take a long time? If that's a valid use case,
>> maybe we should add a WAIT option to let users choose whether to wait for
>> the checkpoint to complete or not?
> 
> Do we want that? The checkpoint is only effective when it's finished,
> and running `psql -c "checkpoint (wait false)"` might make people
> shoot themselves into the foot.

*shrug*

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

> +    <term><literal>MODE</literal></term>
> +    <listitem>
> +     <para>
> +      The <command>CHECKPOINT</command> command forces an immediate
> +      checkpoint by default when the command is issued, without waiting for a
> +      regular checkpoint scheduled by the system. <literal>FAST</literal> is a
> +      synonym for <literal>IMMEDIATE</literal>.
> +     </para>
> +     <para>
> +      A <literal>SPREAD</literal> checkpoint will instead spread out the write load
> +      as determined by the <xref linkend="guc-checkpoint-completion-target"/>
> +      setting, like the system-scheduled checkpoints.
> +     </para>
> +    </listitem>
> +   </varlistentry>

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

> +   <varlistentry>
> +    <term><literal>FLUSH_ALL</literal></term>
> +    <listitem>
> +     <para>
> +      Requests the checkpoint to also flush data of <literal>UNLOGGED</literal>
> +      relations. Defaults to off.
> +     </para>
> +    </listitem>
> +   </varlistentry>

Could we rename this to something like FLUSH_UNLOGGED or INCLUDE_UNLOGGED?
IMHO that's more descriptive.

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.

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).

-- 
nathan