Re: A few new options for CHECKPOINT - Mailing list pgsql-hackers

From Bossart, Nathan
Subject Re: A few new options for CHECKPOINT
Date
Msg-id 8E47A31D-65AD-43B4-96EE-316CCB144616@amazon.com
Whole thread Raw
In response to Re: A few new options for CHECKPOINT  (Laurenz Albe <laurenz.albe@cybertec.at>)
Responses Re: A few new options for CHECKPOINT
Re: A few new options for CHECKPOINT
List pgsql-hackers
Thanks to all for the feedback.  I've attached v2 of the patch.  I've
removed the WAIT and FORCE options and renamed IMMEDIATE to FAST.

On 11/25/20, 7:52 AM, "Stephen Frost" <sfrost@snowman.net> wrote:
> I'm a bit confused by the idea here..  The whole point of running a
> CHECKPOINT is to get the immediate behavior with the IO spike to get
> things flushed out to disk so that, on crash recovery, there's less
> outstanding WAL to replay.
>
> Avoiding the IO spike implies that you're waiting for a regular
> checkpoint and that additional WAL is building up since that started and
> therefore you're going to have to replay that WAL during crash recovery
> and so you won't end up reducing your recovery time, so I'm failing to
> see the point..?  I don't think you really get to have both..  pay the
> price at backup time, or pay it during crash recovery.

It's true that you might not lower recovery time as much as if you did
an immediate checkpoint, but presumably there can still be some
benefit from doing a non-immediate checkpoint.  I think a similar
argument can be made for pg_start_backup(), which AFAICT is presently
the only way to manually request a non-immediate checkpoint.

Nathan


Attachment

pgsql-hackers by date:

Previous
From: David Christensen
Date:
Subject: Re: [PATCH] Add `truncate` option to subscription commands
Next
From: Alvaro Herrera
Date:
Subject: Re: Improper use about DatumGetInt32