Re: segfault with incremental sort

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: James Coleman <jtc331(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, luis(dot)roberto(at)siscobra(dot)com(dot)br, pgsql-bugs <pgsql-bugs(at)lists(dot)postgresql(dot)org>, "alan(dot)formagi" <alan(dot)formagi(at)siscobra(dot)com(dot)br>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
Subject: Re: segfault with incremental sort
Date: 2020-11-30 13:57:25
Message-ID: CAA4eK1KyzicrHzLqtf03q_vwTptgm2=Ota-G-UXAZ1R1+Bd0fQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Wed, Nov 25, 2020 at 8:27 PM James Coleman <jtc331(at)gmail(dot)com> wrote:
>
> On Wed, Nov 25, 2020 at 9:05 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > On Wed, Nov 25, 2020 at 7:57 AM James Coleman <jtc331(at)gmail(dot)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.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message David G. Johnston 2020-11-30 15:32:35 Re: Update on
Previous Message Dave Page 2020-11-30 11:29:06 Re: [External] Re: pgadmin--pgagent---the process hang by unknow reasons