public inbox for [email protected]  

help / color / mirror / Atom feed

From: Bernice Southey <[email protected]>
To: Tom Lane <[email protected]>
Cc: [email protected]
Subject: Re: Is this expected concurrency behaviour for EvalPlanQual and ctid?
Date: Thu, 20 Nov 2025 10:33:00 +0000
Message-ID: <CAEDh4nx9Hx_pm4rCvGhWjgzy_w9qR7Ydiha+D4mchddHZPft7A@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CAEDh4ny-6xDG5FJ9Zp_EQKnTL+ouef_JqKACUo2RNQ9KFKKnXA@mail.gmail.com>
	<CAEDh4nxKnq1txtjRfBd2eDtRdeXEq5Dbi+n+z0MXkqMMBk=vBA@mail.gmail.com>
	<CAEDh4nyxze285Ku=nFahj-3j6+rA2+CkrXFji3PheG4sCKQ7Aw@mail.gmail.com>
	<[email protected]>

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.

view thread (4+ messages)

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: Is this expected concurrency behaviour for EvalPlanQual and ctid?
  In-Reply-To: <CAEDh4nx9Hx_pm4rCvGhWjgzy_w9qR7Ydiha+D4mchddHZPft7A@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox