Re: all_visible replay aborting due to uninitialized pages - Mailing list pgsql-hackers

From Robert Haas
Subject Re: all_visible replay aborting due to uninitialized pages
Date
Msg-id CA+Tgmob2-UahB8vYwDet3VV3tjhShwLa8_JSirRV8HuU7z0Lvw@mail.gmail.com
Whole thread Raw
In response to Re: all_visible replay aborting due to uninitialized pages  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: all_visible replay aborting due to uninitialized pages
List pgsql-hackers
On Wed, May 29, 2013 at 9:57 AM, Andres Freund <andres@2ndquadrant.com> wrote:
>> Thought about that, but given that 9.3's visibilitymap_set already will
>> already FPI heap pages I concluded it wouldn't really be an improvement
>> since it's only one ||log_heap_page or so there. Not sure what's
>> better. Will write the patch and see how it goes.
>
> Ended up using log_newpage_buffer since reusing visibilitymap_set's
> record would break the wal format as we currently do not accept an FPI
> on the heap pages during replay when < 9.3. Forcing to upgrade the
> client first would be rather unfriendly...
>
> That has the disadvantage of logging a full heap page since it doesn't
> use the hole optimization but this happens really infrequently, so ...

Yeah, I think it's fine.  The patch also looks fine, although I think
the comments could use a bit of tidying.  I guess we need to
back-patch this all the way back to 8.4?  It will require some
adjustments for the older branches.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Behavior of a pg_trgm index for 2 (or < 3) character LIKE queries
Next
From: Bruce Momjian
Date:
Subject: Re: Running pgindent