Re: [COMMITTERS] pgsql: Reduce spurious Hot Standby conflicts from never-visible records
От | Simon Riggs |
---|---|
Тема | Re: [COMMITTERS] pgsql: Reduce spurious Hot Standby conflicts from never-visible records |
Дата | |
Msg-id | 1292286507.2737.3574.camel@ebony обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql: Reduce spurious Hot Standby conflicts from never-visible records (Simon Riggs <simon@2ndQuadrant.com>) |
Список | pgsql-hackers |
On Sun, 2010-12-12 at 10:15 +0000, Simon Riggs wrote: > > Also, I'm not totally convinced it's correct when xmin > xmax, > despite > > Simon's follow-up commit to fix that. Shouldn't it advance > > latestRemovedXid to xmin in that case? Or maybe it's ok as it is > because > > we know that xmax committed after xmin. The impression I get from > the comment above the function now is that it advances > latestRemovedXid to > > the highest XID present in the tuple, but that's not what it does in > the xmin > xmax case. That comment needs clarification. > > Hmmm, my earlier code took xmax only if xmax > xmin. That was wrong; > what I have now is better, but your point is there may be an even > better > truth. I'll think on that a little more. This has a stranger answer than I was expecting. HeapTupleSatisfiesVacuum() shows there is no interaction between the xmin of a tuple and the point at which it is removed, if the xmin transaction commits. So the hot standby conflict depends only upon the xmax, meaning that xmin > xmax is not a problem. So no immediate change to the code is warranted, on that specific point. -- Simon Riggs http://www.2ndQuadrant.com/books/PostgreSQL Development, 24x7 Support, Training and Services
В списке pgsql-hackers по дате отправления: