Re: CHECKPOINT unlogged data
Christoph Berg <myon@debian.org>
From: Christoph Berg <myon@debian.org>
To: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: Nathan Bossart <nathandbossart@gmail.com>, Fujii Masao <masao.fujii@oss.nttdata.com>, Andres Freund <andres@anarazel.de>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-06-16T14:36:59Z
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 →
-
Add FLUSH_UNLOGGED option to CHECKPOINT command.
- 8d33fbacbac9 19 (unreleased) landed
-
Add MODE option to CHECKPOINT command.
- 2f698d7f4b7b 19 (unreleased) landed
-
Add option list to CHECKPOINT command.
- a4f126516e68 19 (unreleased) landed
-
Rename CHECKPOINT_FLUSH_ALL to CHECKPOINT_FLUSH_UNLOGGED.
- cd8324cc89a9 19 (unreleased) landed
-
Rename CHECKPOINT_IMMEDIATE to CHECKPOINT_FAST.
- bb938e2c3c7a 19 (unreleased) landed
Attachments
Re: Laurenz Albe > How about the following for added clarity: > > Running an explicit <command>CHECKPOINT</command> is not required during > normal operation; the system schedules checkpoints automatically (controlled > by the settings in <xref linkend="runtime-config-wal-checkpoints"/>). > However, it can be useful to perform an explicit checkpoint immediately > before shutting down the server or performing an online file system backup, > if you want the checkpoint implicit in these operations to be as fast as > possible. In particular, <literal>UNLOGGED</literal> table data only get > flushed to disk during a shutdown checkpoint, so you should use the option > <literal>FLUSH_UNLOGGED</literal> for an explicit checkpoint right before a > shutdown. Thanks for the suggestions. I've taken this one, but replaced "be as fast as possible" by "have to write out less data" to avoid confusion with the FAST mode. > Oh, interesting; I wasn't aware of that. That means that running CHECKPOINT > (FLUSH_UNLOGGED) is less useful than I thought, since there is often already > a spread checkpoint running. Would it be useful to recommend that you should > run the command twice when aiming for a fast shutdown? I spent some time digging through the code, but I'm still not entirely sure what's happening. There are several parts to it: 1) the list of buffers to flush is determined at the beginning of the checkpoint, so running a 2nd FLUSH_UNLOGGED checkpoint will not make the running checkpoint write these 2) running CHECKPOINT updates the checkpoint flags in shared memory so I think the currently running checkpoint picks "MODE FAST" up and speeds up. (But I'm not entirely sure, the call stack is quite deep there.) 3) running CHECKPOINT (at least when waiting for it) seems to actually start a new checkpoint, so FLUSH_UNLOGGED should still be effective. (See the code arount "start_cv" in checkpointer.c) Admittedly, adding these points together raises some question marks about the flag handling, so I would welcome clarification by someone more knowledgeable in this area. > I find this somewhat confusing; how about > How about: Taken unmodified, thanks! Christoph