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.
