From: | Christoph Berg <myon(at)debian(dot)org> |
---|---|
To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
Cc: | Nathan Bossart <nathandbossart(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: CHECKPOINT unlogged data |
Date: | 2025-06-16 14:36:59 |
Message-ID: | aFAsCyMj-mybBlv3@msg.df7cb.de |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
Attachment | Content-Type | Size |
---|---|---|
v5-0001-Rename-checkpoint-options-immediate-and-flush-all.patch | text/x-diff | 17.7 KB |
v5-0002-Add-mode-and-flush_unlogged-options-to-CHECKPOINT.patch | text/x-diff | 11.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2025-06-16 14:40:12 | Re: Fwd: dsm_registry: Add detach and destroy features |
Previous Message | Yura Sokolov | 2025-06-16 14:28:31 | Re: Read-Write optimistic lock (Re: sinvaladt.c: remove msgnumLock, use atomic operations on maxMsgNum) |