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  (James Coleman <jtc331@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: PG Bug reporting form
Дата:
Сообщение: BUG #16752: ODBC driver makes the input SQL query invalid
Следующее
От: "David G. Johnston"
Дата:
Сообщение: Re: Update on