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: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Tender Wang <tndrwang@gmail.com>, jian he <jian.universality@gmail.com>, exclusion@gmail.com, pgsql-bugs@lists.postgresql.org, Amit Langote <amitlangote09@gmail.com>
Date: 2025-10-30T06:44:07Z
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 Thu, 30 Oct 2025 at 10:31, I wrote:
>
>  I mean, we I believe we need to execute
> CheckValidResultRel against all partitions in ExecInitModifyTable, at
> least when no partition pruning has been performed
>

So, the problem is that we managed to exclude all child relations, and
only have a single (dummy) root relation as a result of the
modifyTable plan. Maybe we should populate its target list with
pseudo-junk columns in create_modifytable_plan ?

For instance, they query does not error-out if we have at least one
another non-file-fdw partition:

create table p2 partition of pt for values in ( 2) ;

this is because we have this in create_modifytable_plan

```
/* Transfer resname/resjunk labeling, too, to keep executor happy */
apply_tlist_labeling(subplan->targetlist, root->processed_tlist);
```

and we successfully found a junk column in the p2 partition.

The problem is, it works iff root->processed_tlist has at least one
relation which can give us junk columns. Should we add handling for
corner case here?
Another option is to remove this 'Transfer resname/resjunk labeling'
completely and rework planner-executer contracts somehow.

-- 
Best regards,
Kirill Reshke