Greetings, * Bossart, Nathan (bossa...@amazon.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
signature.asc
Description: PGP signature