Re: CHECKPOINT unlogged data
Christoph Berg <myon@debian.org>
From: Christoph Berg <myon@debian.org>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-05-30T17:23:04Z
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
Re: Nathan Bossart
> This patch also adds an IMMEDIATE option, which I proposed some time ago
> [0]. I ended up withdrawing it due to general skepticism about its
Thanks for the pointer, I did not go that far back when looking for
older threads.
When writing the patch, I was also thinking about naming the option
"fast" or "spread" but ultimately went with "immediate" because that's
what the log message is using:
=# checkpoint;
2025-05-30 18:23:17.433 CEST [579834] LOG: Checkpoint beginnt: immediate force wait
SQL command "(options)" tend to be booleans, hence "immediate {on|off}".
Introducing two separate keywords "fast" and "spread" seemed
confusing, and there is no precedent for "fast=on" in other tools or
the replication protocol.
> usefulness. FWIW I have no concerns about adding a few retail options to
> CHECKPOINT, but others might balk at options without solid use-cases. The
> unlogged table one seems reasonable enough.
I think the two options immediate and flush_all are actually useful in
combination for the shutdown case. If operation is to continue
normally until just before the shutdown, it might make sense to run
these 3 commands (or just #1 and #3):
checkpoint (flush_all, immediate false);
checkpoint (flush_all);
pg_ctl stop
(I also thought about a VERBOSE option, but since the checkpoint
messages are generated by a different process, it's probably harder
than I initially thought.)
Christoph