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-d009f7b7a...@reaktor.fi> Branch ------ master Details ------- http://git.postgresql.org/pg/commitdiff/9c810a2edccaffe0ff48b50d31c47a155e4f9815 Modified Files -------------- src/backend/executor/execIndexing.c | 19 ++++++++++++------- src/test/regress/expected/insert_conflict.out | 23 +++++++++++++++++++++++ src/test/regress/sql/insert_conflict.sql | 14 ++++++++++++++ 3 files changed, 49 insertions(+), 7 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
