Re: Concurrency bug in UPDATE of partition-key

  if (!tuple_deleted)

- return NULL;

+ {

+ /*

+ * epqslot will be typically NULL. But when ExecDelete() finds

+ * that another transaction has concurrently updated the same

+ * row, it re-fetches the row, skips the delete, and epqslot is

+ * set to the re-fetched tuple slot. In that case, we need to

+ * do all the checks again.

+ */

+ if (TupIsNull(epqslot))

+ return NULL;

+ else

+ {

+ slot = ExecFilterJunk(resultRelInfo->ri_junkFilter, epqslot);

+ tuple = ExecMaterializeSlot(slot);

+ goto lreplace;

+ }

+ }

I think this will allow before row delete triggers to be fired more than once.  Normally, if the EvalPlanQual testing generates a new tuple, we don't fire the triggers again.  Now, one possibility could be that we don't skip the delete after a concurrent update and still allow inserts to use a new tuple generated by EvalPlanQual testing of delete.  However, I think we need to perform rechecks for update to check if the modified tuple still requires to be moved to new partition, right or do you have some other reason in mind?