On Sun, 27 Feb 2022 at 17:35, Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote:
> > > + /* > > > + * Project the tuple. In case of a > > > partitioned table, the > > > + * projection was already built to use the > > > root's descriptor, > > > + * so we don't need to map the tuple here. > > > + */ > > > + actionInfo.actionState = action; > > > + insert_slot = ExecProject(action->mas_proj); > > > + > > > + (void) ExecInsert(mtstate, rootRelInfo, > > > + > > > insert_slot, slot, > > > + estate, > > > &actionInfo, > > > + > > > mtstate->canSetTag); > > > + InstrCountFiltered1(&mtstate->ps, 1); > > > > What happens if somebody concurrently inserts a conflicting row? > > An open question to which I don't have any good answer RN. 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. Various cases were not tested in the patch - additional patch attached, but nothing surprising there. ExecInsert() does not return from such an ERROR, so the code fragment appears correct to me. -- Simon Riggs http://www.EnterpriseDB.com/
new_insert_tests_for_merge.patch
Description: Binary data