Re: [COMMITTERS] pgsql: Augment WAL records for btree delete with GetOldestXmin() to
От | Simon Riggs |
---|---|
Тема | Re: [COMMITTERS] pgsql: Augment WAL records for btree delete with GetOldestXmin() to |
Дата | |
Msg-id | 1269766364.3684.2139.camel@ebony обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql: Augment WAL records for btree delete with GetOldestXmin() to (Greg Stark <gsstark@mit.edu>) |
Список | 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 по дате отправления: