Fix incorrect checking of deferred exclusion constraint after a HOT update.
If a row that potentially violates a deferred exclusion constraint is HOT-updated later in the same transaction, the exclusion constraint would be reported as violated when the check finally occurs, even if the row(s) the new row originally conflicted with have since been removed. This happened because the wrong TID was passed to check_exclusion_constraint(), causing the live HOT-updated row to be seen as a conflicting row rather than recognized as the row-under-test. Per bug #13148 from Evan Martin. It's been broken since exclusion constraints were invented, so back-patch to all supported branches. Branch ------ REL9_4_STABLE Details ------- http://git.postgresql.org/pg/commitdiff/4d3d9719d28ff9956540c36a05a4846b55b0234b Modified Files -------------- src/backend/commands/constraint.c | 17 +++++++++++------ src/test/regress/input/constraints.source | 10 ++++++++++ src/test/regress/output/constraints.source | 14 ++++++++++++++ 3 files changed, 35 insertions(+), 6 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
