MIME-Version: 1.0
References: <19355-57d7d52ea4980dc6@postgresql.org> <868ff2a518820c8864b6d28510294b2457a126af.camel@cybertec.at>
 <CANjBVm3AMm=9-mB7=uqJjaWN-+RrA8+w-gXhZn6L7VHu7K_Urw@mail.gmail.com>
 <CAEZATCVcV4cfqGnmPGVxwjsPh7rxsTD510=KOGFyi2_FMgqWaQ@mail.gmail.com>
 <CA+HiwqE8gNK7Utqo2EAKh24KExWfypt06m1EFNXBd5TFDO2f6w@mail.gmail.com>
 <CAHewXNn8ApcYfZKjZ1R8Z7yHRoi+C+mu5r9LbZUbb6691d6Rrw@mail.gmail.com>
 <CAEZATCVr+=F=iTbi3XyABSEr5Cqw=ptm2PyGc75SaQ1JYrPnsg@mail.gmail.com>
 <CAHewXN=D2SUh1CvE0gnk1Ev_k4RAEO9aoEgQZG_7eAuSWxZA0Q@mail.gmail.com>
 <CAEDh4nw=h5NihhuBgq4GFCfPP9vcg54QJ+K0XsG9S0owWDUhfA@mail.gmail.com>
 <CAEDh4nzHw6LciY1A556ybfNB_TmKNa-gSTJAKvEMVi=zJZ8Yig@mail.gmail.com> <CA+HiwqGpeG2jo51o6XoXfFYpoXGg=NM2Byj0Yjk7G1rzr=0mJw@mail.gmail.com>
In-Reply-To: <CA+HiwqGpeG2jo51o6XoXfFYpoXGg=NM2Byj0Yjk7G1rzr=0mJw@mail.gmail.com>
From: Amit Langote <amitlangote09@gmail.com>
Date: Wed, 7 Jan 2026 21:16:34 +0900
Message-ID: <CA+HiwqEpYoC-zMqSrZg80vHT7ZVnQo1Dd2cntpwXzPf3TD6ZkA@mail.gmail.com>
Subject: Re: BUG #19355: Attempt to insert data unexpectedly during concurrent update
To: Bernice Southey <bernice.southey@gmail.com>
Cc: Tender Wang <tndrwang@gmail.com>, Dean Rasheed <dean.a.rasheed@gmail.com>, 
	Bh W <wangbihua.cn@gmail.com>, Laurenz Albe <laurenz.albe@cybertec.at>, 
	pgsql-bugs@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CA%2BHiwqEpYoC-zMqSrZg80vHT7ZVnQo1Dd2cntpwXzPf3TD6ZkA%40mail.gmail.com>
Precedence: bulk

On Wed, Jan 7, 2026 at 6:45=E2=80=AFPM Amit Langote <amitlangote09@gmail.co=
m> wrote:
> On Fri, Jan 2, 2026 at 6:58=E2=80=AFAM Bernice Southey
> <bernice.southey@gmail.com> wrote:
> > I've looked much harder at the code (I'm still at
> > stumbling-around-in-the-dark-with-a-match level) and AFAICT, the two
> > approaches are very similar. I think equal effort is required to check
> > that PlannerGlobal.allRelids, unprunableRelids, and es_unpruned_relids
> > are correct, whichever approach is used. I can't find any missed cases
> > in either approach - with my matchlight.
>
> Good catch on the history -- that's exactly when the bug was
> introduced.

I remembered more on why I insisted on putting only relations with OID
(RTE_RELATION and RTE_SUBQUERY with relid set (views)) into
PlannerGlobal.allRelids and thus PlannedStmt.unprunableRelids. The
reason is that I did not want loops iterating over unprunableRelids to
have to skip relations that do not have an OID. For example,
AcquireExecutorLocks() currently iterates over the rtable and skips
non-RELATION RTEs; in a now-reverted commit (525392d57) I had changed
it to iterate over unprunableRelids instead, which avoided the need
for that skip logic entirely, because unprunableRelids by design only
contains OID-bearing relations:

-       foreach(lc2, plannedstmt->rtable)
+       while ((rtindex =3D bms_next_member(plannedstmt->unprunableRelids,
+                                         rtindex)) >=3D 0)
        {
-           RangeTblEntry *rte =3D (RangeTblEntry *) lfirst(lc2);
+           RangeTblEntry *rte =3D list_nth_node(RangeTblEntry,
+                                              plannedstmt->rtable,
+                                              rtindex - 1);

-           if (!(rte->rtekind =3D=3D RTE_RELATION ||
-                 (rte->rtekind =3D=3D RTE_SUBQUERY && OidIsValid(rte->reli=
d))))
-               continue;
+           Assert(rte->rtekind =3D=3D RTE_RELATION ||
+                  (rte->rtekind =3D=3D RTE_SUBQUERY && OidIsValid(rte->rel=
id)));

This is why adding all RTEs to allRelids, as Tender suggested, would
be problematic -- it would defeat the design intent that allows loops
over unprunableRelids to skip the filtering logic. While there are no
such loops today (I reverted the patch that added one), keeping this
design makes sense. Dean's fix addresses the buggy bms_is_member()
check directly, without changing allRelids - albeit the name's a bit
misleading as has been mentioned.

--
Thanks, Amit Langote