Re: BUG #19099: Conditional DELETE from partitioned table with non-updatable partition raises internal error
amit <amitlangote09@gmail.com>
From: Amit Langote <amitlangote09@gmail.com>
To: Kirill Reshke <reshkekirill@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:23:16Z
Lists: pgsql-bugs
Attachments
- v3-0001-Fix-bogus-ctid-requirement-for-dummy-root-partiti.patch (application/octet-stream)
Hi, On Fri, Nov 7, 2025 at 6:05 PM Kirill Reshke <reshkekirill@gmail.com> wrote: > 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. > > 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