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 |
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 |