aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/gist/gistproc.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2016-07-04 16:09:11 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2016-07-04 16:09:11 -0400
commit31ce32ade428dd3ea11ea468f8bdd6492b991ed1 (patch)
tree92020270d0379cfee5e58e45449765894b733e6d /src/backend/access/gist/gistproc.c
parente612181686b54a0311a85247c7f1640dee53636f (diff)
downloadpostgresql-31ce32ade428dd3ea11ea468f8bdd6492b991ed1.tar.gz
postgresql-31ce32ade428dd3ea11ea468f8bdd6492b991ed1.zip
Fix failure to handle conflicts in non-arbiter exclusion constraints.
ExecInsertIndexTuples treated an exclusion constraint as subject to noDupErr processing even when it was not listed in arbiterIndexes, and would therefore not error out for a conflict in such a constraint, instead returning it as an arbiter-index failure. That led to an infinite loop in ExecInsert, since ExecCheckIndexConstraints ignored the index as-intended and therefore didn't throw the expected error. To fix, make the exclusion constraint code path use the same condition as the index_insert call does to decide whether no-error-for-duplicates behavior is appropriate. While at it, refactor a little bit to avoid unnecessary list_member_oid calls. (That surely wouldn't save anything worth noticing, but I find the code a bit clearer this way.) Per bug report from Heikki Rauhala. Back-patch to 9.5 where ON CONFLICT was introduced. Report: <4C976D6B-76B4-434C-8052-D009F7B7AEDA@reaktor.fi>
Diffstat (limited to 'src/backend/access/gist/gistproc.c')
0 files changed, 0 insertions, 0 deletions