SELECT FOR UDPATE behavior inside joins - Mailing list pgsql-general

From Khan, Tanzeel
Subject SELECT FOR UDPATE behavior inside joins
Date
Msg-id CH5PR18MB927659676A86C64F0EF16E91A8CDBFA@CH5PR18MB927659.namprd18.prod.outlook.com
Whole thread Raw
Responses Re: SELECT FOR UDPATE behavior inside joins
Re: SELECT FOR UDPATE behavior inside joins
List pgsql-general
Hi,

I am trying to understand the SELECT FOR UPDATE behavior when it is not returning rows back to client.

postgres=> CREATE TABLE t (col1 INT, col2 INT);
postgres=> INSERT INTO t VALUES (1, 1);

S1: BEGIN; UPDATE t SET col2 = col2 + 1 WHERE col1 = 1;
S2: BEGIN; WITH cte AS (SELECT * FROM t WHERE col1 = 1 FOR UPDATE) UPDATE t SET col2 = t.col2 + 1 FROM cte AS t_self_join WHERE (t.col2 = t_self_join.col2);
S1: COMMIT;
S2: zero rows updated

Why does session 2 update zero rows ? Shouldn’t the SELECT FOR UPDATE and UPDATE read the new version of the row as per
> If so, the second updater proceeds with its operation using the updated version of the row. In the case of SELECT FOR UPDATE and SELECT FOR SHARE, this means it is the updated version of the row that is locked and returned to the client.

Does this mean the new version for row is only returned when the SELECT FOR SHARE is returning rows back to client ?

------
Thanks,
Tanzeel

pgsql-general by date:

Previous
From: Jehan-Guillaume de Rorthais
Date:
Subject: Re: psql: print values and return the COUNT(*) value to bash?
Next
From: hubert depesz lubaczewski
Date:
Subject: Re: psql: print values and return the COUNT(*) value to bash?