Re: heapgetpage() and ->takenDuringRecovery

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: heapgetpage() and ->takenDuringRecovery
Date: 2014-03-03 12:39:55
Message-ID: CA+TgmoboVb8pq58J027vhHFCJZt64YSXoi7Qu5rbjP4sT9dx-w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Mar 3, 2014 at 7:07 AM, Andres Freund <andres(at)2ndquadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2014-03-03 12:41:10 Re: Defining macro LSNOID for pg_lsn in pg_type.h
Previous Message Robert Haas 2014-03-03 12:15:47 Re: Dump pageinspect to 1.2: page_header with pg_lsn datatype