Re: BUG #17117: FailedAssertion at planner.c
От | David Rowley |
---|---|
Тема | Re: BUG #17117: FailedAssertion at planner.c |
Дата | |
Msg-id | CAApHDvqy1GPi3OYXVXKH3hLpiNp9FdRHjQj=3cp-vhWt94Y0Nw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #17117: FailedAssertion at planner.c (David Rowley <dgrowleyml@gmail.com>) |
Ответы |
Re: BUG #17117: FailedAssertion at planner.c
|
Список | pgsql-bugs |
On Fri, 23 Jul 2021 at 00:28, David Rowley <dgrowleyml@gmail.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
Вложения
В списке pgsql-bugs по дате отправления: