Amit Kapila writes:
> Right, so I have moved "Failed assertion in parallel worker
> (ExecInitSubPlan)" item to CLOSE_WAIT state as I don't think there is any
> known pending issue in that item. I have moved it to CLOSE_WAIT state
> because we have derived our queries to reproduce the problem base
On Sat, Jun 11, 2016 at 2:07 PM, Andreas Seltenreich
wrote:
>
> Amit Kapila writes:
>
> > I have moved it to CLOSE_WAIT state because we have derived our
> > queries to reproduce the problem based on original report[1]. If next
> > run of sqlsmith doesn't show any problem in this context then we
Amit Kapila writes:
> I have moved it to CLOSE_WAIT state because we have derived our
> queries to reproduce the problem based on original report[1]. If next
> run of sqlsmith doesn't show any problem in this context then we will
> move it to resolved.
I don't have access to my testing horse pow
On Fri, Jun 10, 2016 at 8:20 PM, Tom Lane wrote:
>
> Amit Kapila writes:
> > On Thu, Jun 9, 2016 at 11:38 PM, Tom Lane wrote:
> >> Robert Haas writes:
> >>> Could you answer my question about whether adjust_appendrel_attrs()
> >>> might translate Vars into non-Vars?
>
> >> Yes, absolutely.
>
>
On Thu, Jun 9, 2016 at 8:17 PM, Tom Lane wrote:
> I wrote:
>> Robert Haas writes:
>>> There's one other related thing I'm concerned about, which is that the
>>> code in namespace.c that manages pg_temp doesn't know anything about
>>> parallelism. So it will interpret pg_temp to mean the pg_temp_N
On Fri, Jun 10, 2016 at 10:50 AM, Tom Lane wrote:
> Amit Kapila writes:
>> On Thu, Jun 9, 2016 at 11:38 PM, Tom Lane wrote:
>>> Robert Haas writes:
Could you answer my question about whether adjust_appendrel_attrs()
might translate Vars into non-Vars?
>
>>> Yes, absolutely.
>
>> Isn't
Amit Kapila writes:
> On Thu, Jun 9, 2016 at 11:38 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> Could you answer my question about whether adjust_appendrel_attrs()
>>> might translate Vars into non-Vars?
>> Yes, absolutely.
> Isn't this true only for UNION ALL cases and not for inheritance c
On Thu, Jun 9, 2016 at 11:38 PM, Tom Lane wrote:
>
> Robert Haas writes:
>
> > Could you answer my question about whether adjust_appendrel_attrs()
> > might translate Vars into non-Vars?
>
> Yes, absolutely.
Isn't this true only for UNION ALL cases and not for inheritance child
relations (at lea
I wrote:
> Robert Haas writes:
>> There's one other related thing I'm concerned about, which is that the
>> code in namespace.c that manages pg_temp doesn't know anything about
>> parallelism. So it will interpret pg_temp to mean the pg_temp_NNN
>> schema for its own backend ID rather than the lea
On Thu, Jun 9, 2016 at 2:08 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jun 9, 2016 at 1:44 PM, Tom Lane wrote:
>>> Well, yeah, you could remove it. It's inappropriate. The right place
>>> for such an error check is an attempt to actually access any data within
>>> a temp table, ie so
Robert Haas writes:
> On Thu, Jun 9, 2016 at 1:44 PM, Tom Lane wrote:
>> Well, yeah, you could remove it. It's inappropriate. The right place
>> for such an error check is an attempt to actually access any data within
>> a temp table, ie someplace in localbuf.c. There is no reason a worker
>>
On Thu, Jun 9, 2016 at 1:44 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jun 9, 2016 at 1:02 PM, Tom Lane wrote:
>>> It seems like the only reason that we would need such a flag is that
>>> applying has_parallel_hazard() to a Var is a bit expensive thanks to
>>> the typeid_is_temp() test
Robert Haas writes:
> On Thu, Jun 9, 2016 at 1:02 PM, Tom Lane wrote:
>> It seems like the only reason that we would need such a flag is that
>> applying has_parallel_hazard() to a Var is a bit expensive thanks to
>> the typeid_is_temp() test --- but if you ask me, that test is stupid
>> and shou
On Thu, Jun 9, 2016 at 1:02 PM, Tom Lane wrote:
> Robert Haas writes:
>> Don't generate parallel paths for rels with parallel-restricted outputs.
>
> Surely this bit is wrong on its face:
>
> @@ -971,6 +980,7 @@ set_append_rel_size(PlannerInfo *root, RelOptInfo *rel,
> adjust_appendre
14 matches
Mail list logo
