Horton

Re: Killing off removed rels properly

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alexander Lakhin <exclusion@gmail.com>
Cc: Richard Guo <guofenglinux@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2023-02-20T16:33:28Z
Lists: pgsql-hackers 
Alexander Lakhin <exclusion@gmail.com> writes:
> After this change the following query triggers an assert:

> CREATE TABLE tt (tid integer PRIMARY KEY) PARTITION BY LIST (tid);
> CREATE TABLE ttp PARTITION OF tt DEFAULT;
> CREATE TABLE st (sid integer);

> MERGE INTO tt USING st ON tt.tid = st.sid WHEN NOT MATCHED THEN INSERT 
> VALUES (st.sid);

Hmph.  Yeah, I think that's just wrong: the cases of found-a-baserel
and didn't-find-a-baserel should be treating MERGE-rejection identically.
This is probably broken even before e9a20e451.

Thanks for the report!

			regards, tom lane

Commits

  1. Prevent join removal from removing the query's result relation.

  2. Remove gratuitous assumptions about what make_modifytable can see.

  3. When removing a relation from the query, drop its RelOptInfo.

  4. Allow left join removals and unique joins on partitioned tables