Re: SELECT FOR UDPATE behavior inside joins
| От | Khan, Tanzeel |
|---|---|
| Тема | Re: SELECT FOR UDPATE behavior inside joins |
| Дата | |
| Msg-id | CH5PR18MB927659CE30CC405704D6D81E6DCDBAA@CH5PR18MB927659.namprd18.prod.outlook.com обсуждение исходный текст |
| Ответ на | Re: SELECT FOR UDPATE behavior inside joins (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | 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.
> 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
В списке pgsql-general по дате отправления: