Re: A few new options for CHECKPOINT
От | Bossart, Nathan |
---|---|
Тема | Re: A few new options for CHECKPOINT |
Дата | |
Msg-id | 23F78743-C688-444F-BDF2-3F427F713266@amazon.com обсуждение исходный текст |
Ответ на | Re: A few new options for CHECKPOINT (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: A few new options for CHECKPOINT
|
Список | pgsql-hackers |
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. Nathan
В списке pgsql-hackers по дате отправления: