Re: heapgetpage() and ->takenDuringRecovery - Mailing list pgsql-hackers

From Robert Haas
Subject Re: heapgetpage() and ->takenDuringRecovery
Date
Msg-id CA+TgmoboVb8pq58J027vhHFCJZt64YSXoi7Qu5rbjP4sT9dx-w@mail.gmail.com
Whole thread Raw
In response to Re: heapgetpage() and ->takenDuringRecovery  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
On Mon, Mar 3, 2014 at 7:07 AM, Andres Freund <andres@2ndquadrant.com> wrote:
>> I don't think there's any reason to believe that lazy_scan_heap() can
>> only hit pages that are empty or have just been defragged.  Suppose
>> that there's a tuple on the page which was recently inserted; the
>> inserting transaction has committed but there are some backends that
>> still have older snapshots.  The page won't be marked all-visible
>> because it isn't.  Now, eventually those older snapshots will go away,
>> and sometime after that the relation will get vacuumed again, and
>> we'll once again look the page.  But this time we notice that it is
>> all-visible, and mark it so.
>
> Hm, right, that can happen. How about adding a LSN interlock in
> visibilitymap_set() for those cases as well, not just for checksums?

Well, if I'm correctly understanding what you're proposing, that would
involve emitting an FPI for each page when we vacuum the
newly-inserted portion of an insert-only table.  That's been
repeatedly proposed in the past, but I've opposed it on the grounds
that it makes vacuum much more expensive in such cases.

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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Dump pageinspect to 1.2: page_header with pg_lsn datatype
Next
From: Michael Paquier
Date:
Subject: Re: Defining macro LSNOID for pg_lsn in pg_type.h