On 12/5/20, 9:11 AM, "Stephen Frost" <sfr...@snowman.net> wrote: > * Bossart, Nathan (bossa...@amazon.com) wrote: >> On 12/5/20, 6:41 AM, "Stephen Frost" <sfr...@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.
I plan to mark this patch as withdrawn after the next commitfest unless anyone objects. Nathan
