Greetings,
* Bossart, Nathan (bossartn@amazon.com) wrote:
> On 12/5/20, 6:41 AM, "Stephen Frost" <sfrost@snowman.net> wrote:
> > 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?
>
> If it's enough to just wait for the current checkpoint to complete or
> to wait for the next one to complete, I suppose you could just poll
> pg_control_checkpoint(). I think the only downside is that you could
> end up sitting idle for a while, especially if checkpoint_timeout is
> high and checkpoint_completion_target is low. But, as you point out,
> that may not be a typically recommended way to configure the system.
Maybe I missed something, but aren't you going to be waiting a while
with this patch given that it's asking for a spread checkpoint too..?
I agree that you could just monitor for the next checkpoint using
pg_control_checkpoint(), which is why I'm wondering again what the
point is behind this patch... I'm trying to understand why we'd be
encouraging people to increase the number of checkpoints that are
happening when they're still going to be waiting around for that spread
(in other words, non-immediate) checkpoint to happen (just as if they'd
just waited until the next regular checkpoint), and they're still going
to have a fair bit of WAL to replay because it'll be however much WAL
has been written since we started the spread/non-immediate checkpoint.
Thanks,
Stephen
