Re: Is this expected concurrency behaviour for EvalPlanQual and ctid?

On Wed, Nov 19, 2025 at 8:04 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> > The same thing happens with
> > update t set i = 2 from (select i from t for update) x where t.i = x.i;
>
> Right, the common advice if you need to make such scenarios work
> is to add FOR UPDATE to the non-target relations. But here, that
> just breaks in the opposite direction: the sub-select blocks
> waiting for the concurrent commit and then returns x.i = 2.
> But the UPDATE's initial scan of t only sees t.i = 1, so the join
> fails before we ever get to EvalPlanQual.

Thanks for the clear explanation. When I tried to think this through I
couldn't fill in the details.