On Sun, 27 Feb 2022 at 17:35, Alvaro Herrera <alvherre@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/
