| From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
|---|---|
| To: | Bernd Helmle <mailings(at)oopsware(dot)de>, Michael Paquier <michael(at)paquier(dot)xyz>, "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com> |
| Cc: | "'Bossart, Nathan'" <bossartn(at)amazon(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: A few new options for CHECKPOINT |
| Date: | 2020-11-25 15:04:36 |
| Message-ID: | 1b097b167ecdcc903962cbe55526cdfa2c4e97cb.camel@cybertec.at |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, 2020-11-25 at 11:41 +0100, Bernd Helmle wrote:
> Am Mittwoch, den 25.11.2020, 13:47 +0900 schrieb Michael Paquier:
>
> > I can see the use case for IMMEDIATE, but I fail to see the use cases
> > for WAIT and FORCE. CHECKPOINT_FORCE is internally implied for the
> > end-of-recovery and shutdown checkpoints. WAIT could be a dangerous
> > thing if disabled, as clients could pile up requests to the
> > checkpointer for no real purpose.
>
> Wouldn't it be more convenient to use "FAST" for immediate checkpoint,
> defaulting to "FAST ON"? That would be along the parameter used in the
> streaming protocol command BASE_BACKUP, where "FAST" disables lazy
> checkpointing.
+1
That would also match pg_basebackup's "-c fast|spread".
Yours,
Laurenz Albe
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Konstantin Knizhnik | 2020-11-25 15:14:44 | Transaction isolation and table contraints |
| Previous Message | Konstantin Knizhnik | 2020-11-25 15:00:16 | Re: Implementing Incremental View Maintenance |