On 2020-Dec-05, Stephen Frost wrote:
> 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.
You keep making this statement, and I don't necessarily disagree, but if
that is the case, please explain why don't we have
checkpoint_completion_target set to 0.9 by default? Should we change
that?
> 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?
Yes, I agree that the use case for this is unclear.