On 8 June 2012 05:01, Tom Lane <t...@sss.pgh.pa.us> wrote: > Peter Geoghegan <pe...@2ndquadrant.com> writes: >> On 7 June 2012 18:03, Robert Haas <robertmh...@gmail.com> wrote: >>> On Thu, Jun 7, 2012 at 12:52 PM, Simon Riggs <si...@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.
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers