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

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: [COMMITTERS] pgsql: Augment WAL records for btree delete with GetOldestXmin() to
Дата
Msg-id 407d949e1003271539h2513882bucc691390615d7c63@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [COMMITTERS] pgsql: Augment WAL records for btree delete with GetOldestXmin() to  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: [COMMITTERS] pgsql: Augment WAL records for btree delete with GetOldestXmin() to  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
On Sat, Mar 27, 2010 at 7:36 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Sat, 2010-03-27 at 19:15 +0000, Greg Stark wrote:
> > 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.

Slip through? I'm not following you.


> 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.

I don't like having dependencies on the precise logic in vacuum rather
than only on the guarantees that vacuum provides. We want to improve
the logic in vacuum and hot pruning to cover more cases and that will
be harder if there's code elsewhere depending on its simple-minded xid
<= globalxmin test.


-- 
greg


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

Предыдущее
От: Gokulakannan Somasundaram
Дата:
Сообщение: A Bug in outDatum ?? (Not Sure )
Следующее
От: Tom Lane
Дата:
Сообщение: Re: A Bug in outDatum ?? (Not Sure )