Re: BUG #19355: Attempt to insert data unexpectedly during concurrent update - Mailing list pgsql-bugs

From Amit Langote
Subject Re: BUG #19355: Attempt to insert data unexpectedly during concurrent update
Date
Msg-id CA+HiwqGSogk5__9rFp9F6TGDpyM11CTVQHy5GRptGZC3A4DwwA@mail.gmail.com
Whole thread Raw
In response to Re: BUG #19355: Attempt to insert data unexpectedly during concurrent update  (Amit Langote <amitlangote09@gmail.com>)
Responses Re: BUG #19355: Attempt to insert data unexpectedly during concurrent update
List pgsql-bugs
On Thu, Jan 8, 2026 at 10:16 PM Amit Langote <amitlangote09@gmail.com> wrote:
> On Wed, Jan 7, 2026 at 9:52 PM Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
> > On Wed, 7 Jan 2026 at 09:37, Amit Langote <amitlangote09@gmail.com> wrote:
> > >
> > > Yes, I think the approach in your patch seems better for the reason
> > > you mentioned, at least for back-patching sanity.
> > >
> > > I intended all of these relid sets to account for prunable RELATION RTEs only.
> >
> > Yes, I think that makes sense.
> >
> > > Thanks Tender and Bernice for the additional analysis. I prefer Dean's
> > > fix-the-executor approach for back-patching. Bernice, are there other
> > > related issues you're aware of beyond this rowmark bug? Want to make
> > > sure Dean's patch covers them too.
> >
> > It looks to me as though either approach would work, so I'm happy for
> > you to decide which approach fits best with your design.
>
> Ok, I thought about this some more.
>
> I admit I'd be lying if I said I didn't have doubts about my original
> design. It might be better for PlannedStmt.unprunableRelids and
> es_unpruned_relids to cover *all* RTEs except those that are prunable
> (decided by the planner) or pruned (decided during executor startup).
> That way, code checking these sets wouldn't need to also verify the
> RTE kind, as your patch currently does.
>
> If we were to change the design, we could remove
> PlannerGlobal.allRelids entirely on master, since it would no longer
> need to be selectively populated -- unprunableRelids could just be
> computed directly from the full rtable. But that would mean we'd be
> leaving v18 with an unused field in PlannerGlobal. That's not great,
> but having different designs in the two branches isn't ideal either.
>
> So I'll go with your minimal fix for the back-patch. We can revisit
> the design cleanup on master later if desired.
>
> > > Thanks for the patch!  Do you intend to commit and back-patch this
> > > yourself, or would you like me to handle it?
> >
> > It's your code, and you're more familiar with it than me, so I'm happy
> > to leave it to you :-)
>
> Surely.

Here's Dean patch with a commit message added.  I plan to commit it
barring objections.

--
Thanks, Amit Langote

Attachment

pgsql-bugs by date:

Previous
From: ma lz
Date:
Subject: 回复: uninitialized var in encnames.c
Next
From: PG Bug reporting form
Date:
Subject: BUG #19379: Role pg_read_all_data don't allowed read large objects