On Wed, Oct 12, 2016 at 8:50 PM, Albe Laurenz <laurenz.albe@xxxxxxxxxx> wrote: > Kevin Grittner wrote: >> On Tue, Oct 11, 2016 at 2:29 PM, Jason Dusek <jason.dusek@xxxxxxxxx> wrote: >>> I notice the following oddity: >> >>> =# CREATE TABLE with_pk (i integer PRIMARY KEY); >>> CREATE TABLE >> >>> =# BEGIN; >>> BEGIN >>> =# INSERT INTO with_pk VALUES (2), (2) ON CONFLICT DO NOTHING; >>> ERROR: could not serialize access due to concurrent update >>> =# END; >>> ROLLBACK >> >> I don't see that on development HEAD. What version are you >> running? What is your setting for default_transaction_isolation? > > The subject says SERIALIZABLE, and I can see it on my 9.5.4 database: > > test=> CREATE TABLE with_pk (i integer PRIMARY KEY); > CREATE TABLE > test=> START TRANSACTION ISOLATION LEVEL SERIALIZABLE; > START TRANSACTION > test=> INSERT INTO with_pk VALUES (2), (2) ON CONFLICT DO NOTHING; > ERROR: could not serialize access due to concurrent update This happens in both SERIALIZABLE and REPEATABLE READ when a single command inserts conflicting rows with an ON CONFLICT cause, and it comes from the check in ExecCheckHeapTupleVisible whose comment says: /* * ExecCheckHeapTupleVisible -- verify heap tuple is visible * * It would not be consistent with guarantees of the higher isolation levels to * proceed with avoiding insertion (taking speculative insertion's alternative * path) on the basis of another tuple that is not visible to MVCC snapshot. * Check for the need to raise a serialization failure, and do so as necessary. */ So it seems to be working as designed. Perhaps someone could argue that you should make an exception for tuples inserted by the current command. -- Thomas Munro http://www.enterprisedb.com -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
