On Mon, Aug 13, 2012 at 6:19 PM, Jeff Janes <[email protected]> wrote: > On Sat, Jun 9, 2012 at 5:43 AM, Tom Lane <[email protected]> wrote: >> Simon Riggs <[email protected]> writes: >>> So now the standard for my patches is that I must consider what will >>> happen if the xlog is deleted? >> >> When you're messing around with something that affects data integrity, yes. >> The long and the short of it is that this patch does reduce our ability >> to recover from easily-foreseeable disasters. The problem it was meant >> to solve is not dire enough to justify that, and other fixes are >> possible that don't require any compromises in this dimension. >> So please revert. We can revisit the original complaint in 9.3. > > This reversion was done, so > b8b69d89905e04b910bcd Wed Jun 13, 2012 > reverted: > 18fb9d8d21a28caddb72 Wed Nov 2, 2011. > > However, the corresponding doc changes 43342891861cc2d08de and > bd2396988a1afbcb6424 were not reverted. > > A simple reversion is probably not the right thing, because the > original docs seemed rather inadequate. > > I've attached an attempt to fix this. I also changed "WAL shipping" > to "WAL archiving", as the reason for setting archive_timeout applies > to all WAL archiving not just the special case of warm standby.
Committed, thanks. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
