From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Geoghegan <peter(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Avoiding adjacent checkpoint records |
Date: | 2012-06-08 06:44:24 |
Message-ID: | CA+U5nMKEjvqv0jHcsioUf=f5L_XJbLOXuUHcFT36p8x-+rq7jg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 8 June 2012 05:01, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Peter Geoghegan <peter(at)2ndquadrant(dot)com> writes:
>> On 7 June 2012 18:03, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> On Thu, Jun 7, 2012 at 12:52 PM, Simon Riggs <simon(at)2ndquadrant(dot)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.
Apart from the likely point that hint bits exist on disk...
> 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.
So now the standard for my patches is that I must consider what will
happen if the xlog is deleted?
Tell me such a rule is applied uniformly to all patches then I would be happy.
I will revoke, not because of the sense in this argument but because
you personally ask for it.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2012-06-08 08:10:29 | Re: WalSndWakeup() and synchronous_commit=off |
Previous Message | Craig Ringer | 2012-06-08 06:04:41 | Re: pg_basebackup blocking all queries with horrible performance |