On Sat, 27 Jun 2026 at 20:22, Bharath Rupireddy
<bharath.rupireddyforpostgres@gmail.com> wrote:
>
> In short: with a BEFORE UPDATE trigger, the trigger's tuple lock
> advances tupleid to the concurrently-updated row version, so the later
> table_tuple_update returns TM_Ok instead of TM_Updated. Since oldSlot
> is only refreshed on the TM_Updated path, the RETURNING clause keeps
> the pre-wait value (ctid=(0,1), n=7) instead of the actual
> concurrently-updated value (ctid=(0,2), n=17). Without the trigger,
> the wait happens inside table_tuple_update itself, which returns
> TM_Updated and correctly refreshes oldSlot.
Yes, that analysis seems correct.
This doesn't affect DELETE, because the DELETE code always fetches the
most recent version of the old tuple just before processing the
RETURNING clause. Similarly, it doesn't affect a cross-partition
UPDATE, which does a DELETE followed by an INSERT.
It also doesn't affect MERGE UPDATE/DELETE, because that does its own
EPQ handling, rather than relying on the trigger code to do it (see
9321c79c86e).
So I think we just need something like the attached.
Regards,
Dean
