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)
