Re: A few new options for CHECKPOINT

Greetings,

* Bossart, Nathan (bossartn(at)amazon(dot)com) wrote:
> This all seems reasonable to me. I've attached a new version of the
> patch.

diff --git a/doc/src/sgml/ref/checkpoint.sgml b/doc/src/sgml/ref/checkpoint.sgml
index 2afee6d7b5..2b1e56fbd7 100644
--- a/doc/src/sgml/ref/checkpoint.sgml
+++ b/doc/src/sgml/ref/checkpoint.sgml
+ <para>
+ Note that the server may consolidate concurrently requested checkpoints or
+ restartpoints. Such consolidated requests will contain a combined set of
+ options. For example, if one session requested a spread checkpoint and
+ another session requested a fast checkpoint, the server may combine these
+ requests and perform one fast checkpoint.
+ </para>

[ ... ]

+ <refsect1>
+ <title>Parameters</title>
+
+ <variablelist>
+ <varlistentry>
+ <term><literal>SPREAD</literal></term>
+ <listitem>
+ <para>
+ Specifies that checkpoint activity should be throttled based on the
+ setting for the <xref linkend="guc-checkpoint-completion-target"/>
+ parameter. If the option is turned off, <command>CHECKPOINT</command>
+ creates a checkpoint or restartpoint as fast as possible. By default,
+ <literal>SPREAD</literal> is turned off, and the checkpoint activity is
+ not throttled.
+ </para>
+ </listitem>
+ </varlistentry>

So- just to be clear, CHECKPOINTs are more-or-less always happening in
PG, and running this command might do something or might end up doing
nothing depending on if a checkpoint is already in progress and this
request just gets consolidated into an existing one, and it won't
actually reduce the amount of WAL replay except in the case where
checkpoint completion target is set to make a checkpoint happen in less
time than checkpoint timeout, which ultimately isn't a great way to run
the system anyway.

Assuming we actually want to do this, which I still generally don't
agree with since it isn't really clear if it'll actually end up doing
something, or not, wouldn't it make more sense to have a command that
just sits and waits for the currently running (or next) checkpoint to
complete..? For the use-case that was explained, at least, we don't
actually need to cause another checkpoint to happen, we just want to
know when a checkpoint has completed, right?

Is there some other reason for this that isn't being explained..?

Thanks,

Stephen