Re: BUG #19099: Conditional DELETE from partitioned table with non-updatable partition raises internal error

Hi,

On Fri, Nov 7, 2025 at 6:05 PM Kirill Reshke <reshkekirill(at)gmail(dot)com> wrote:
> On Fri, 7 Nov 2025 at 11:02, Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> >
> > On Thu, Nov 6, 2025 at 7:00 PM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> > > I looked at a few options, but none seem non-invasive enough for
> > > back-patching, apart from the first patch I posted. That one makes
> > > ExecInitModifyTable() not require a ctid to be present to set the root
> > > partitioned table’s ri_RowIdAttNo, except in the case of MERGE, which
> > > seems to need it. The corner case that triggers the internal error for
> > > UPDATE/DELETE doesn’t occur for MERGE now and likely won’t when
> > > foreign tables eventually gain MERGE support; don't mark my words
> > > though ;-).
> >
> > Well, OK, I just had not tried hard enough to see that the same error
> > happens for MERGE too.
> >
> > With my patch applied:
> > EXPLAIN VERBOSE MERGE INTO pt t USING (VALUES (1, 'x'::text)) AS s(a,
> > b) ON false WHEN MATCHED THEN UPDATE SET b = s.b;
> > ERROR: could not find junk ctid column
> >
> > I have another idea: we can simply recognize the corner condition that
> > throws this error in ExecInitModifyTable() by checking if
> > ModifyTable.resultRelations contains only the root partitioned table.
> > That can only happen for UPDATE, DELETE, or MERGE when all child
> > relations were excluded.
> >
> > Patch doing that attached. Added test cases to file_fdw's suite.
>
> HI!
>
> I think this is an OK option for backpatching. After v2 applied, I
> found the behavior of DELETE and EXPLAIN DELETE consistent.

Thanks for the comment.

> The only
> remaining issue is VERBOSE output difference with or without
> enable_partition_pruning (which is v19+ issue to worry about),
> correct?

Yes, iff we are to do anything at all about the difference.

> Also, should we add COSTS OFF to EXPLAIN in the regression test? I
> understand that costs should be always zero, but COSTS OFF is almost
> everywhere is tests

Yeah, a good call.

v3 attached.

--
Thanks, Amit Langote