Horton

Re: CHECKPOINT unlogged data

Andres Freund <andres@anarazel.de>

View thread
From: Andres Freund <andres@anarazel.de>
To: Christoph Berg <myon@debian.org>
Cc: Nathan Bossart <nathandbossart@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-05-30T17:29:08Z
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 →

  1. Add FLUSH_UNLOGGED option to CHECKPOINT command.

  2. Add MODE option to CHECKPOINT command.

  3. Add option list to CHECKPOINT command.

  4. Rename CHECKPOINT_FLUSH_ALL to CHECKPOINT_FLUSH_UNLOGGED.

  5. Rename CHECKPOINT_IMMEDIATE to CHECKPOINT_FAST.

On 2025-05-30 19:23:04 +0200, Christoph Berg wrote:
> 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.

I'd add a 'mode' that can be set to an arbitrary string, which then can be
validated in C code. That seems more future proof.