Re: segfault with incremental sort
От | Amit Kapila |
---|---|
Тема | Re: segfault with incremental sort |
Дата | |
Msg-id | CAA4eK1KyzicrHzLqtf03q_vwTptgm2=Ota-G-UXAZ1R1+Bd0fQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: segfault with incremental sort (James Coleman <jtc331@gmail.com>) |
Ответы |
Re: segfault with incremental sort
|
Список | pgsql-bugs |
On Wed, Nov 25, 2020 at 8:27 PM James Coleman <jtc331@gmail.com> wrote: > > On Wed, Nov 25, 2020 at 9:05 AM Amit Kapila <amit.kapila16@gmail.com> wrote: > > > > On Wed, Nov 25, 2020 at 7:57 AM James Coleman <jtc331@gmail.com> wrote: > > > > > > > It is possible but we don't that the context unless subplan is marked > > parallel-safe. I think if we need to generate parallel-safe plans for > > correlated queries, we might want to see how the subplan will be > > marked parallel-safe. > > The one possibility I can imagine right now is maintaining some kind > of flag that marks a subplan as "parallel safe except for params" and > then recheck the params to see if the specific usage is safe. Does > something like that seem reasonable? Other than the param, the subplan > would be marked safe by the existing code. > I don't know. What I remember is it is not easy to check the params to see if the specific usage is safe for correlated sub-queries as detecting the level of param was tricky. Basically, whether the param can be generated below Gather node so that it could be used was a bit tricky but maybe I had missed something obvious during my analysis. However, feel free to give it a try. > > > That is, if > > > we re-run the checks on testexpr and args in this context, then we'll > > > not find anything parallel unsafe about them (the param can safely be > > > found in the current context), so we'll be free to execute the subplan > > > in workers. > > > > > > > Now, I think it is quite possible that in PG-13 we have > > > > unintentionally allowed plans containing correlated sub-queries but > > > > missed to take care of it at all required places. > > > > > > Yes, we're discussing a fix in [1] for PG13's missing checks for > > > parallel safety here. > > > > > > > So, are you trying to make such plans (which have correlated > > sub-queries) parallel-safe or parallel-unsafe? > > In PG13 we accidentally made this case generate a parallel plan > because we were missing a parallel safety check when choosing a sort > expression. So for PG13's next patch release we'll be looking to get > in that parallel safety check, which will result in this particular > plan being excluded. > Okay, this was what I was wondering about. -- With Regards, Amit Kapila.
В списке pgsql-bugs по дате отправления: