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?