Horton

Re: CHECKPOINT unlogged data

Christoph Berg <myon@debian.org>

View thread
From: Christoph Berg <myon@debian.org>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Laurenz Albe <laurenz.albe@cybertec.at>, Fujii Masao <masao.fujii@oss.nttdata.com>, Andres Freund <andres@anarazel.de>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-06-16T15:43:54Z
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.

Attachments

Re: Nathan Bossart
> I think you've got it right.  With CHECKPOINT_WAIT set, RequestCheckpoint()
> will wait for a new checkpoint to start, at which point we know that the
> new flags have been seen by the checkpointer.  If an immediate checkpoint
> is pending, CheckpointWriteDelay() will skip sleeping in the
> currently-running one, so the current checkpoint will be "upgraded" to
> immediate in some sense, but IIUC there will still be another immediate
> checkpoint after it completes.  But AFAICT it doesn't pick up
> FLUSH_UNLOGGED until the next checkpoint begins.

> Another thing to note is what I mentioned earlier:

Thanks. I now have this:

  <para>
   If a checkpoint is already running when a <command>CHECKPOINT</command>
   is issued, a new checkpoint is queued.  The server will consolidate multiple
   concurrently requested checkpoints or restartpoints and merge their options.
   For example, if one session requests a fast checkpoint and another session
   requests a spread checkpoint, the server combines these requests and
   performs one fast checkpoint.  Queing a fast checkpoint will also switch a
   currently running spread checkpoint to run fast.
  </para>

Christoph