Re: Avoiding adjacent checkpoint records

Peter Geoghegan <peter@2ndquadrant.com> writes:
> On 7 June 2012 18:03, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Thu, Jun 7, 2012 at 12:52 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>> Clearly, delaying checkpoint indefinitely would be a high risk choice.
>>> But they won't be delayed indefinitely, since changes cause WAL
>>> records to be written and that would soon cause another checkpoint.

>> But that's exactly the problem - it might not be soon at all.

> Your customer's use-case seems very narrow, and your complaint seems
> unusual to me, but couldn't you just get the customer to force
> checkpoints in a cronjob or something? CheckPointStmt will force,
> provided !RecoveryInProgress() .

I think both you and Simon have completely missed the point.  This
is not a "use case" in the sense of someone doing it deliberately.
This is about data redundancy, ie, if you lose your WAL through some
unfortunate mishap, are you totally screwed or is there a reasonable
chance that the data is on-disk in the main data store?  I would guess
that the incidents Robert has been talking about were cases where EDB
were engaged to do crash recovery, and were successful precisely because
PG wasn't wholly dependent on the WAL copy of the data.

This project has always put reliability first.  It's not clear to me why
we would compromise that across-the-board in order to slightly reduce
idle load in replication configurations.  Yeah, it's probably not a
*large* compromise ... but it is a compromise, and one that doesn't
seem to me to be very well-advised.  We can fix the idle-load issue
without compromising on this basic goal; it will just take more than
a ten-line patch to do it.
        regards, tom lane