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

From Greg Stark
Subject Re: [COMMITTERS] pgsql: Augment WAL records for btree delete with GetOldestXmin() to
Date
Msg-id 407d949e1003271539h2513882bucc691390615d7c63@mail.gmail.com
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Augment WAL records for btree delete with GetOldestXmin() to  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: [COMMITTERS] pgsql: Augment WAL records for btree delete with GetOldestXmin() to
List 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 by date:

Previous
From: Gokulakannan Somasundaram
Date:
Subject: A Bug in outDatum ?? (Not Sure )
Next
From: Tom Lane
Date:
Subject: Re: A Bug in outDatum ?? (Not Sure )