pgsql: Augment WAL records for btree delete with GetOldestXmin() to
in [PgSql]
|
Prev: changes to documentation build
Next: pgsql: Augment WAL records for btree deletewith GetOldestXmin() to
From: Greg Stark on 27 Mar 2010 15:15 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? -- greg -- 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: Greg Stark on 27 Mar 2010 18:39
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. > 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |