On Wed, Mar 24, 2021 at 2:13 AM Mark Dilger
<mark.dilger@enterprisedb.com> wrote:
> The visibility rules fix is different in v11, relying on a visibility check which more closely follows the
implementationof 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