On Wed, Mar 24, 2021 at 2:13 AM Mark Dilger <mark.dil...@enterprisedb.com> wrote: > The visibility rules fix is different in v11, relying on a visibility check > which more closely follows the implementation of > HeapTupleSatisfiesVacuumHorizon.
Hmm. The header comment you wrote says "If a tuple might not be visible to any running transaction, then we must not check it." But, I don't find that statement very clear: does it mean "if there could be even one transaction to which this tuple is not visible, we must not check it"? Or does it mean "if the number of transactions that can see this tuple could potentially be zero, then we must not check it"? I don't think either of those is actually what we care about. I think what we should be saying is "if the tuple could have been inserted by a transaction that also added a column to the table, but which ultimately did not commit, then the table's current TupleDesc might differ from the one used to construct this tuple, so we must not check it." -- Robert Haas EDB: http://www.enterprisedb.com
