Alvaro Herrera wrote: > Alvaro Herrera wrote: > > > I'm thinking about the comparison of full infomask as you propose > > instead of just the bits that we actually care about. I think the only > > thing that could cause a spurious failure (causing an extra execution of > > the HeapTupleSatisfiesUpdate call and the stuff below) is somebody > > setting HEAP_XMIN_COMMITTED concurrently; but that seems infrequent > > enough that it should pretty harmless. However, should we worry about > > possible future infomask bit changes that could negatively affect this > > behavior? > > Here's a complete patch illustrating what I mean. This is slightly more > expensive than straight infomask comparison in terms of machine > instructions, but that seems okay to me.
I have pushed a slightly tweaked version of this, after verifying that it solves the problem in Andrew's test environment. Josh, if you could verify that it solves the problem for you too, it'd be great. Thanks for the report and test case. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
