On Wed, Nov 19, 2025 at 8:04 PM Tom Lane <[email protected]> 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.
