Re: BUG #17117: FailedAssertion at planner.c

On Thu, 22 Jul 2021 at 23:23, PG Bug reporting form
<noreply@postgresql.org> wrote:
> CREATE TABLE v0 ( DEC TEXT , v3 INTEGER , v2 INTEGER , v1 INTEGER ) ;
> CREATE RULE v3 AS ON INSERT TO v0 DO INSTEAD VALUES ( - ( WITH v1 ( v2 ) AS
> ( SELECT - - 127 INTERSECT SELECT v1 + -1 FROM v0 ) SELECT ( SELECT ( SELECT
> ARRAY [ - 2147483647 , 63 , - 0 ] ) [ -2147483648 ] FROM v0 ) ) = - - 8 , -
> - 75 , 25 ) ;
> WITH NONE AS ( DELETE FROM v0 USING LATERAL ( SELECT * FROM ( SELECT
> DISTINCT * FROM v0 POSITION WHERE ( v1 , v3 ) = ANY ( SELECT v3 , v2 FROM v0
> WHERE v2 < - 61 ) AND v3 <= 59 UNION ALL SELECT * FROM v0 TABLESAMPLE SYSTEM
> ( - 21 ) ) v2 WHERE v3 = v1 ) v2 RETURNING * ) INSERT INTO v0 VALUES ( - - -
> - - 16 , 127 , - - - - -128 ) ;

This can be simplified to:

create table t1 (a int);
create rule t1_rule as on insert to t1 do instead values(1);
with cte as (delete from v0 returning *) insert into v0 values(2);

I'm unsure if parse->hasModifyingCTE is not being set properly and
that's causing PlannerGlobal.parallelModeOK to be set incorrectly in
standard_planner or if we should just be never setting anything to
parallelModeOK that's not parse->querySource == QSRC_ORIGINAL.

I might not have enough time to look into this further, so if anyone
else is lurking, feel free.

David