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

From Simon Riggs
Subject Re: [COMMITTERS] pgsql: Augment WAL records for btree delete with GetOldestXmin() to
Date
Msg-id 1269766364.3684.2139.camel@ebony
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Augment WAL records for btree delete with GetOldestXmin() to  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
On Sat, 2010-03-27 at 22:39 +0000, Greg Stark wrote:
> 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.

No, there is no possibility for it to slip through, you're right. (After
much thinking).

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

Agreed

-- Simon Riggs           www.2ndQuadrant.com



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: plpgsql's case bug?
Next
From: Robert Haas
Date:
Subject: Re: join removal