Re: BUG #17117: FailedAssertion at planner.c

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: cyg0810(at)gmail(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #17117: FailedAssertion at planner.c
Date: 2021-07-22 13:58:50
Message-ID: CAApHDvqy1GPi3OYXVXKH3hLpiNp9FdRHjQj=3cp-vhWt94Y0Nw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Fri, 23 Jul 2021 at 00:28, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> 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);

That was meant to be:

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 t1 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 think the hasModifyingCTE going missing is the problem here.

What seems to be going on is that we have a DO INSTEAD rule to change
an INSERT on t1 to a SELECT, (the "values(1)" clause). When we find
the INSERT in the query with the CTE, we change the parse to the
rewritten one due to the DO INSERT rule so that the entire query
becomes:

with cte as (delete from v0 returning *) values(1);

however, along the way when replacing the parse after copying in the
CTEs from the original, we forget to also set hasModifyingCTE if it
was set in the original query.

I think the fix is what I've attached, however, I don't often get a
chance to look at the rewriter in detail, so I'd be happy if someone
else took a look to see if they agree.

David

Attachment Content-Type Size
dont_forget_about_hasModifyingCTE_when_running_insteadof_rules.patch application/octet-stream 549 bytes

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Dmitry Marakasov 2021-07-22 14:06:34 Re: BUG #16696: Backend crash in llvmjit
Previous Message John Naylor 2021-07-22 12:43:10 Re: BUG #17115: psqlODBC Unicode(x64) driver treats a boolean field as text