Thread: pgsql: Reduce spurious Hot Standby conflicts from never-visible records

Reduce spurious Hot Standby conflicts from never-visible records.
Hot Standby conflicts only with tuples that were visible at
some point. So ignore tuples from aborted transactions or for
tuples updated/deleted during the inserting transaction when
generating the conflict transaction ids.

Following detailed analysis and test case by Noah Misch.
Original report covered btree delete records, correctly observed
by Heikki Linnakangas that this applies to other cases also.
Fix covers all sources of cleanup records via common code.
Includes additional fix compared to commit on HEAD

Branch
------
REL9_0_STABLE

Details
-------
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=a804a23e7af0e075b88e7b03bfd9b0f22d2657b2

Modified Files
--------------
src/backend/access/heap/heapam.c    |   31 +++++++++++++++++++++++--------
src/backend/access/heap/pruneheap.c |    1 -
src/backend/access/nbtree/nbtxlog.c |   19 +++++--------------
3 files changed, 28 insertions(+), 23 deletions(-)

Simon Riggs <simon@2ndQuadrant.com> writes:
> Reduce spurious Hot Standby conflicts from never-visible records.
> Hot Standby conflicts only with tuples that were visible at
> some point. So ignore tuples from aborted transactions or for
> tuples updated/deleted during the inserting transaction when
> generating the conflict transaction ids.

> Following detailed analysis and test case by Noah Misch.
> Original report covered btree delete records, correctly observed
> by Heikki Linnakangas that this applies to other cases also.
> Fix covers all sources of cleanup records via common code.
> Includes additional fix compared to commit on HEAD

ISTM HeapTupleHeaderAdvanceLatestRemovedXid is still pretty broken,
in that it's examining xmax without having checked that xmax is (a)
valid or (b) a lock rather than a deletion xmax.

            regards, tom lane