Re: BUG #17094: FailedAssertion at planner.c

Richard Guo <guofenglinux(at)gmail(dot)com> writes:
> On Thu, Jul 8, 2021 at 5:27 PM PG Bug reporting form <noreply(at)postgresql(dot)org>
> wrote:
>> CREATE TABLE v0 ( v4 INT , v3 INT UNIQUE , v2 INT , v1 INT UNIQUE ) ;
>> CREATE OR REPLACE RULE v1 AS ON INSERT TO v0 DO INSTEAD NOTIFY COMPRESSION
>> ;
>> WITH v2 AS ( INSERT INTO v0 VALUES ( 0 ) ) DELETE FROM v0 WHERE v3 = - - -
>> - 48 ;

> Seems the Query from RewriteRule->actions may have a NULL jointree, and
> that triggers the SEGV in replace_empty_jointree().

I'm inclined to think we have to reject cases like this. In HEAD,
replace_empty_jointree is the first thing to crash, but if you
try it in back branches it crashes someplace else. Even if we
patched all the planner issues, there's no way for the executor
to handle this, because it has no provisions for a utility statement
as part of a plan tree.

Conceivably the NOTIFY could be removed from the query altogether and
then executed as a separate top-level command, but I'm not sure that
would have desirable semantics.

We do already reject some related cases:

regression=# WITH v2 AS ( INSERT INTO v0 VALUES ( 0 ) ) SELECT * FROM v2;
ERROR: WITH query "v2" does not have a RETURNING clause
LINE 1: WITH v2 AS ( INSERT INTO v0 VALUES ( 0 ) ) SELECT * FROM v2;
^
regression=# WITH v2 AS ( INSERT INTO v0 VALUES ( 0 ) returning * ) SELECT * FROM v2;
ERROR: cannot perform INSERT RETURNING on relation "v0"
HINT: You need an unconditional ON INSERT DO INSTEAD rule with a RETURNING clause.

Also, if you make it an ALSO not INSTEAD rule:

regression=# CREATE OR REPLACE RULE v1 AS ON INSERT TO v0 DO also NOTIFY COMPRESSION;
CREATE RULE
regression=# WITH v2 AS ( INSERT INTO v0 VALUES ( 0 ) ) DELETE FROM v0 WHERE v3 = - - -
regression-# 48;
ERROR: DO ALSO rules are not supported for data-modifying statements in WITH

So it feels to me like this is just a missed case. We don't really
support any cases involving a rule-added NOTIFY in WITH.

regards, tom lane