Re: heapgetpage() and ->takenDuringRecovery

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: heapgetpage() and ->takenDuringRecovery
Дата
Msg-id CA+TgmoboVb8pq58J027vhHFCJZt64YSXoi7Qu5rbjP4sT9dx-w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: heapgetpage() and ->takenDuringRecovery  (Andres Freund <andres@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Dump pageinspect to 1.2: page_header with pg_lsn datatype
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Defining macro LSNOID for pg_lsn in pg_type.h