Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtps  (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.94.2)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1uNZo2-004mJk-U3
	for pgsql-hackers@arkaria.postgresql.org; Fri, 06 Jun 2025 16:20:34 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.94.2)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1uNZny-00DJeu-Sv
	for pgsql-hackers@arkaria.postgresql.org; Fri, 06 Jun 2025 16:20:31 +0000
Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29])
	by malur.postgresql.org with esmtps  (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.94.2)
	(envelope-from <cb@df7cb.de>)
	id 1uNZny-00DJe6-JD
	for pgsql-hackers@lists.postgresql.org; Fri, 06 Jun 2025 16:20:31 +0000
Received: from mout-p-201.mailbox.org ([2001:67c:2050:0:465::201])
	by magus.postgresql.org with esmtps  (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.96)
	(envelope-from <cb@df7cb.de>)
	id 1uNZnw-000ZXa-1X
	for pgsql-hackers@lists.postgresql.org;
	Fri, 06 Jun 2025 16:20:29 +0000
Received: from smtp2.mailbox.org (smtp2.mailbox.org
 [IPv6:2001:67c:2050:b231:465::2])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest
 SHA256)
	(No client certificate requested)
	by mout-p-201.mailbox.org (Postfix) with ESMTPS id 4bDRPM50kBz9tGL;
	Fri,  6 Jun 2025 18:20:23 +0200 (CEST)
Date: Fri, 6 Jun 2025 18:20:21 +0200
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>
Subject: Re: CHECKPOINT unlogged data
Message-ID: <aEMVRbmqqg-aaxAN@msg.df7cb.de>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <aEMIrLUDOKgmE_0P@nathan>
X-Rspamd-Queue-Id: 4bDRPM50kBz9tGL
List-Id: <pgsql-hackers.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-hackers@lists.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-hackers>
Archived-At: 
 <https://www.postgresql.org/message-id/aEMVRbmqqg-aaxAN%40msg.df7cb.de>
Precedence: bulk

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