Обсуждение: 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