| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
| Cc: | Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: "variable not found in subplan target list" |
| Date: | 2023-03-28 13:17:00 |
| Message-ID: | 3463118.1680009420@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
I wrote:
> I reduced this down to
> MERGE INTO public.target_parted as target_0
> USING public.itest1 as ref_0
> ON target_0.b = ref_0.a
> WHEN NOT MATCHED
> THEN INSERT VALUES (42, 13);
> The critical moving part seems to just be that the MERGE target
> is a partitioned table ... but surely somebody tested that before?
Oh, it's not just any partitioned table:
regression=# \d+ target_parted
Partitioned table "public.target_parted"
Column | Type | Collation | Nullable | Default | Storage | Compression | Stats target | Description
--------+---------+-----------+----------+---------+---------+-------------+--------------+-------------
a | integer | | | | plain | | |
b | integer | | | | plain | | |
Partition key: LIST (a)
Number of partitions: 0
The planner is reducing the scan of target_parted to
a dummy scan, as is reasonable, but it forgets to
provide ctid as an output from that scan; then the
parent join node is unhappy because it does have
a ctid output. So it looks like the problem is some
shortcut we take while creating the dummy scan.
I suppose that without the planner bug, this'd fail at
runtime for lack of a partition to put (42,13) into.
Because of that, the case isn't really interesting
for production, which may explain the lack of reports.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jehan-Guillaume de Rorthais | 2023-03-28 13:17:45 | Re: Memory leak from ExecutorState context? |
| Previous Message | Ashutosh Bapat | 2023-03-28 12:58:23 | Re: Hash table scans outside transactions |