pgsql: Augment WAL records for btree deletewith GetOldestXmin() to
in [PgSql]
|
From: Simon Riggs on 27 Mar 2010 15:36 On Sat, 2010-03-27 at 19:15 +0000, Greg Stark wrote: > On Sat, Mar 27, 2010 at 10:10 AM, Simon Riggs <simon(a)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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Simon Riggs on 28 Mar 2010 04:52 On Sat, 2010-03-27 at 22:39 +0000, Greg Stark wrote: > On Sat, Mar 27, 2010 at 7:36 PM, Simon Riggs <simon(a)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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
|
Pages: 1 Prev: pgsql: Augment WAL records for btree delete with GetOldestXmin() to Next: plpgsql's case bug? |