Re: SELECT FOR UDPATE behavior inside joins

From: "Khan, Tanzeel" <tzlkhan(at)amazon(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: SELECT FOR UDPATE behavior inside joins
Date: 2026-01-01 08:40:40
Message-ID: CH5PR18MB927659CE30CC405704D6D81E6DCDBAA@CH5PR18MB927659.namprd18.prod.outlook.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-general

> Since the CTE has FOR UPDATE, it blocks and returns the updated-by-S1
> version of the row. But the outer query initially reads the old
> version of the row, so the join condition fails, and we never get
> to the lock-row-and-recheck behavior of UPDATE.

I see, thanks.

> I am not sure what you are hoping to accomplish with that self-join.
> I suppose this is an oversimplified example, but it's too
> oversimplified for anyone to see why you'd want to do it like that.

I was original trying to build a generic way for fetching old rows in
UPDATE RETURNING clause for pre-18 versions but the self join does
not work well with concurrent updates either resulting in lost updates
or not returning the concurrently updated value in RETURNING.

-----------
Thanks,
Tanzeel

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Eric Ridge 2026-01-06 15:22:23 pg18 bug? SELECT query doesn't work
Previous Message Adrian Klaver 2025-12-31 15:35:38 Re: SELECT FOR UDPATE behavior inside joins