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  (Stephen Frost <sfrost@snowman.net>)
Список 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 по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: automatic analyze: readahead - add "IO read time" log message
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: A few new options for CHECKPOINT