| From: | Bernd Helmle <mailings(at)oopsware(dot)de> |
|---|---|
| To: | 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 10:41:19 |
| Message-ID: | 1812a4818ed13f8f3fc9aef99e999ae20e843392.camel@oopsware.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
I agree that the other options don't seem reasonable for exposing to
SQL.
--
Thanks,
Bernd
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fujii Masao | 2020-11-25 11:19:36 | Re: Add statistics to pg_stat_wal view for wal related parameter tuning |
| Previous Message | 方徳輝 | 2020-11-25 10:10:13 | Re: Is postgres ready for 2038? |