Re: Avoiding adjacent checkpoint records

On Mon, Aug 13, 2012 at 6:19 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> On Sat, Jun 9, 2012 at 5:43 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Simon Riggs <simon(at)2ndQuadrant(dot)com> 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