Re: BUG #19099: Conditional DELETE from partitioned table with non-updatable partition raises internal error
| От | Amit Langote |
|---|---|
| Тема | Re: BUG #19099: Conditional DELETE from partitioned table with non-updatable partition raises internal error |
| Дата | |
| Msg-id | CA+HiwqHe+qQ9BY3RSOqCN50bwWGve-QCoRJaDwhzpy_B91BC6A@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: BUG #19099: Conditional DELETE from partitioned table with non-updatable partition raises internal error (Kirill Reshke <reshkekirill@gmail.com>) |
| Ответы |
Re: BUG #19099: Conditional DELETE from partitioned table with non-updatable partition raises internal error
|
| Список | pgsql-bugs |
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
Вложения
В списке pgsql-bugs по дате отправления: