Re: Back-branch bugs with fully-prunable UPDATEs

On Sun, Apr 7, 2019 at 5:28 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> This test script works fine in HEAD:
>
> drop table if exists parttbl cascade;
> CREATE TABLE parttbl (a int, b int) PARTITION BY LIST (a);
> CREATE TABLE parttbl_1 PARTITION OF parttbl FOR VALUES IN (NULL,500,501,502);
> UPDATE parttbl SET a = NULL, b = NULL WHERE a = 1600 AND b = 999;
>
> In v11, it suffers an assertion failure in ExecSetupPartitionTupleRouting.
>
> In v10, it doesn't crash, but we do get
>
> WARNING:  relcache reference leak: relation "parttbl" not closed
>
> which is surely a bug as well.
>
> (This is a boiled-down version of the script I mentioned in
> https://www.postgresql.org/message-id/13344.1554578481@sss.pgh.pa.us)

What we did in the following commit is behind this:

commit 58947fbd56d1481a86a03087c81f728fdf0be866
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Fri Feb 22 12:23:00 2019 -0500

    Fix plan created for inherited UPDATE/DELETE with all tables excluded.

Before this commit, partitioning related code in the executor could
always rely on the fact that ModifyTableState.resultRelInfo[] only
contains *leaf* partitions.  As of this commit, it may contain the
root partitioned table in some cases, which breaks that assumption.

I've attached fixes for PG 10 and 11, modifying ExecInitModifyTable()
and inheritance_planner(), respectively.

> This seems to be related to what Amit Langote complained of in
> https://www.postgresql.org/message-id/21e7eaa4-0d4d-20c2-a1f7-c7e96f4ce440@lab.ntt.co.jp
> but since there's no foreign tables involved at all, either it's
> a different bug or he misdiagnosed what he was seeing.

I think that one is a different bug, but maybe I haven't looked closely enough.

Thanks,
Amit