Re: segfault with incremental sort - Mailing list pgsql-bugs

From James Coleman
Subject Re: segfault with incremental sort
Date
Msg-id CAAaqYe9UeEVZyBMUJVFmmKf=WdYBLmG=9oQVayMosQ40rP_FaQ@mail.gmail.com
Whole thread Raw
In response to Re: segfault with incremental sort  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-bugs
On Mon, Nov 30, 2020 at 8:56 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> 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.

Thanks. I have some work in progress that seems to show promise so
far; I hope to post about it in a new thread later this week.

James



pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #16753: 'expected 2-element int8 array' error while getting data using query with subquery
Next
From: "qiuchenjun@highgo.com"
Date:
Subject: 回复: Re: A documents mistaken of PG12.5