Re: [COMMITTERS] pgsql: Augment WAL records for btree delete with GetOldestXmin() to

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: [COMMITTERS] pgsql: Augment WAL records for btree delete with GetOldestXmin() to
Дата
Msg-id 1269718607.3684.1967.camel@ebony
обсуждение исходный текст
Ответ на Re: [COMMITTERS] pgsql: Augment WAL records for btree delete with GetOldestXmin() to  (Greg Stark <gsstark@mit.edu>)
Ответы Re: [COMMITTERS] pgsql: Augment WAL records for btree delete with GetOldestXmin() to  (Greg Stark <gsstark@mit.edu>)
Список pgsql-hackers
On Sat, 2010-03-27 at 19:15 +0000, Greg Stark wrote:
> On Sat, Mar 27, 2010 at 10:10 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> > It appears that in practice many of the index items point to heap items
> > that are LP_DEAD. So for the purposes of accessing a heap tuple's xmin,
> > then we're both right. To the current purpose the tuple has been
> > removed, though you are also right: its stub remains.
> 
> If we're pruning an index entry to a heap tuple that has been HOT
> pruned wouldn't the HOT pruning record have already conflicted with
> any queries that could see  it?

Quite probably, but a query that started after that record arrived might
slip through. We have to treat each WAL record separately.

Do you agree with the conjecture? That LP_DEAD items can be ignored
because their xid would have been earlier than the latest LP_NORMAL
tuple we find? (on any page).

Or is a slightly less strong condition true: we can ignore LP_DEAD items
on a page that is also referenced by an LP_NORMAL item.

-- Simon Riggs           www.2ndQuadrant.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Proposal: access control jails (and introduction as aspiring GSoC student)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: join removal