Re: BUG #19536: UPDATE RETURNING OLD value is stale after concurrent update when table has a BEFORE UPDATE trigger

Hi,

On Tue, Jun 30, 2026 at 1:35 AM Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> wrote:
>
> I did think of that, but I was uneasy about copying the trigger's old
> tuple after trigger invocation, in case the trigger scribbled on it
> somehow.

Fair argument. I'm convinced.

> Actually, I think a neater long-term solution would be to move all the
> EPQ rechecking and re-computing of the new tuple out of trigger.c, and
> let the caller deal with it, as we do for the MERGE code

Agreed.

> Yes, that's right. The caller does not initialise context->tmfd at
> all, and ExecUpdatePrologue() doesn't touch it if there are no
> triggers.

That works for me.

> OK, I've added a bunch of tests for those cases. As expected, they
> pass even without the code changes, but it's good to confirm that.

Nice, thank you for adding those.

> > Could we add some context to the error message, e.g., mentioning that
> > this happens after processing the BEFORE UPDATE row triggers? That
> > would make it easier to distinguish from the other similar ones.
>
> I'm pretty sure this is a can't-happen error condition, but OK.

Thanks.

Sorry for the late response. I took a look at the v2 patch, tested it
locally, and it looks good to me. I think we should backpatch this fix
down to PG18 (commit 80feb727c86).

--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com