| From: | "Bossart, Nathan" <bossartn(at)amazon(dot)com> |
|---|---|
| To: | Stephen Frost <sfrost(at)snowman(dot)net> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, "Bernd Helmle" <mailings(at)oopsware(dot)de>, "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: A few new options for CHECKPOINT |
| Date: | 2020-12-05 17:03:00 |
| Message-ID: | 23F78743-C688-444F-BDF2-3F427F713266@amazon.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 12/5/20, 6:41 AM, "Stephen Frost" <sfrost(at)snowman(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Frost | 2020-12-05 17:10:40 | Re: A few new options for CHECKPOINT |
| Previous Message | Stephen Frost | 2020-12-05 16:39:26 | Re: automatic analyze: readahead - add "IO read time" log message |