On 2022-Mar-10, Simon Riggs wrote: > Duplicate rows should produce a uniqueness violation error in one of > the transactions, assuming there is a constraint to define the > conflict. Without such a constraint there is no conflict. > > Concurrent inserts are checked by merge-insert-update.spec, which > correctly raises an ERROR in this case, as documented.
Agreed -- I think this is reasonable. > Various cases were not tested in the patch - additional patch > attached, but nothing surprising there. Thank you, I've included this in all versions of the patch since you sent it. > ExecInsert() does not return from such an ERROR, so the code fragment > appears correct to me. I think trying to deal with it in a different way (namely: suspend processing the inserting WHERE NOT MATCHED clause and switch to processing the row using WHERE MATCHED clauses) would require us use speculative tokens, similar to the way INSERT ON CONFLICT does. I'm not sure we want to go there, but it seems okay to leave that for a later patch. Moreover, there would be no compatibility hit from doing so. -- Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/ "La persona que no quería pecar / estaba obligada a sentarse en duras y empinadas sillas / desprovistas, por cierto de blandos atenuantes" (Patricio Vogel)