Horton

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

Kirill Reshke <reshkekirill@gmail.com>

View thread
From: Kirill Reshke <reshkekirill@gmail.com>
To: Amit Langote <amitlangote09@gmail.com>
Cc: David Rowley <dgrowleyml@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Tender Wang <tndrwang@gmail.com>, jian he <jian.universality@gmail.com>, exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2025-11-07T09:04:53Z
Lists: pgsql-bugs

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix bogus ctid requirement for dummy-root partitioned targets

On Fri, 7 Nov 2025 at 11:02, Amit Langote <amitlangote09@gmail.com> wrote:
>
> On Thu, Nov 6, 2025 at 7:00 PM Amit Langote <amitlangote09@gmail.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.
>
> --
> Thanks, Amit Langote


HI!

I think this is an OK option for backpatching.  After v2 applied, I
found the behavior of DELETE and EXPLAIN DELETE consistent. The only
remaining issue is VERBOSE output difference with or without
enable_partition_pruning (which is v19+ issue to worry about),
correct?

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

-- 
Best regards,
Kirill Reshke