Fix incorrect checking of deferred exclusion constraint after a HOT update.
authorTom Lane <tgl@sss.pgh.pa.us>
Mon, 11 May 2015 16:25:28 +0000 (12:25 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Mon, 11 May 2015 16:25:43 +0000 (12:25 -0400)
commit20781765f77c1fb6465aba97d211636ce92e7a0e
tree0bb028620bb679f030b513f1f0cfcfac3f9e3046
parentb4d4ce1d50bbdf82cd2e2c1c7172b936df01c01d
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.
src/backend/commands/constraint.c
src/test/regress/input/constraints.source
src/test/regress/output/constraints.source