On Thu, Oct 13, 2016 at 3:16 PM, Kevin Grittner <kgrittn@xxxxxxxxx> wrote: > On Thu, Oct 13, 2016 at 2:16 PM, Peter Geoghegan <pg@xxxxxxx> wrote: >> We must still determine if a fix along the lines of the one proposed >> by Thomas is basically acceptable (that is, that it does not clearly >> break any documented guarantees, even if it is overly strict). >> Separately, I'd be interested in seeing how specifically we could do >> better with the patch that you have in the works for this. > > Basically, rather than just failing, I think we should call > CheckForSerializableConflictOut() (which determines whether the > tuple we are reading causes a rw-conflict between our current > transaction and the transaction which last wrote that tuple) and > PredicateLockTuple() (which tells later updates or deletes that > we've read the tuple). I'm wondering whether the error is appropriate on the INSERT ... ON CONFLICT UPDATE case. For example, with ExecCheckHeapTupleVisible() commented out, this does not violate the SERIALIZABLE requirements (which is that the behavior of any set of concurrent serializable transactions which successfully commit must be consistent with running them one at a time in some order): CREATE TABLE with_pk (i integer PRIMARY KEY, v text); -- T1: START TRANSACTION ISOLATION LEVEL SERIALIZABLE; INSERT INTO with_pk VALUES (4) ON CONFLICT DO NOTHING; -- T2: START TRANSACTION ISOLATION LEVEL SERIALIZABLE; INSERT INTO with_pk AS t VALUES (8) ON CONFLICT (i) DO UPDATE SET v = 'updated'; -- T2 blocks, waiting for T1 -- T1: COMMIT; -- T2 unblocks and does the "ON CONFLICT ... UPDATE" -- T2: COMMIT; It seems to me that the result is consistent with T1 -> T2. There is no cycle in the apparent order of execution, and no error is needed. Can you show a case where there is a problem? -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
