On Thu, Jun 9, 2016 at 10:44 AM, Amit Kapila wrote:
> No, I don't have a test case. I have tried a bit, but it seems even if
> there is a problem, one needs to spend quite some time to generate an exact
> test. I think the current patch fixes the reproducible problem [1], so lets
> go with it. W
On Thu, Jun 9, 2016 at 7:44 PM, Robert Haas wrote:
>
> On Thu, Jun 9, 2016 at 9:37 AM, Amit Kapila
wrote:
> > On Thu, Jun 9, 2016 at 8:47 AM, Robert Haas
wrote:
> >> On Mon, Jun 6, 2016 at 6:07 AM, Amit Kapila
> >> wrote:
> >> > That seems doable, as for such rels we can only have Vars and
> >>
On Thu, Jun 9, 2016 at 9:37 AM, Amit Kapila wrote:
> On Thu, Jun 9, 2016 at 8:47 AM, Robert Haas wrote:
>> On Mon, Jun 6, 2016 at 6:07 AM, Amit Kapila
>> wrote:
>> > That seems doable, as for such rels we can only have Vars and
>> > PlaceHolderVars in targetlist. Basically, whenever we are addi
On Thu, Jun 9, 2016 at 8:47 AM, Robert Haas wrote:
>
> On Mon, Jun 6, 2016 at 6:07 AM, Amit Kapila
wrote:
> > That seems doable, as for such rels we can only have Vars and
> > PlaceHolderVars in targetlist. Basically, whenever we are adding
> > PlaceHolderVars to a relation, just remember that i
On Mon, Jun 6, 2016 at 6:07 AM, Amit Kapila wrote:
> That seems doable, as for such rels we can only have Vars and
> PlaceHolderVars in targetlist. Basically, whenever we are adding
> PlaceHolderVars to a relation, just remember that information and use it
> later. The patch doing the same is at
On Sat, Jun 4, 2016 at 1:53 AM, Robert Haas wrote:
>
> On Thu, May 12, 2016 at 2:07 PM, Tom Lane wrote:
> >> Err, wow. That makes my head hurt. Can you explain why this case
> >> only arises for appendrel children, and not for plain rels?
> >
> > Well, plain rels only output Vars ;-)
>
> Hmm.
On Wed, Jun 1, 2016 at 9:35 PM, Noah Misch wrote:
> [Action required within 72 hours. This is a generic notification.]
>
> The above-described topic is currently a PostgreSQL 9.6 open item. Robert,
> since you committed the patch believed to have created it, you own this open
> item. If some ot
On Thu, May 12, 2016 at 2:07 PM, Tom Lane wrote:
>> Err, wow. That makes my head hurt. Can you explain why this case
>> only arises for appendrel children, and not for plain rels?
>
> Well, plain rels only output Vars ;-)
Hmm. Dilip's example in
https://www.postgresql.org/message-id/CAFiTN-vzg
On Sat, May 7, 2016 at 9:07 AM, Amit Kapila wrote:
> From the above output it is clear that parallel restricted function is
> pushed down below gather node. I found that though we have have care fully
> avoided to push pathtarget below GatherPath in apply_projection_to_path() if
> pathtarget cont
On Thu, May 26, 2016 at 05:08:31PM +0530, Amit Kapila wrote:
> Just to summarize, apart from above issue, we have discussed two different
> issues related to parallel query in this thread.
> a. Push down of parallel restricted clauses to nodes below gather. Patch
> to fix same is posted upthread [
On Thu, May 12, 2016 at 11:37 PM, Tom Lane wrote:
>
> Robert Haas writes:
> >> Target list for a relation, you mean? See relation.h:
> >>
> >> * reltarget - Default Path output tlist for this rel; normally
contains
> >> * Var and PlaceHolderVar nodes for the values we need
On Sun, May 22, 2016 at 9:32 PM, Andreas Seltenreich
wrote:
>
> Amit Kapila writes:
>
> > avoid_restricted_clause_below_gather_v1.patch
> > prohibit_parallel_clause_below_rel_v1.patch
>
> I didn't observe any parallel worker related coredumps since applying
> these. The same amount of testing don
Amit Kapila writes:
> avoid_restricted_clause_below_gather_v1.patch
> prohibit_parallel_clause_below_rel_v1.patch
I didn't observe any parallel worker related coredumps since applying
these. The same amount of testing done before applying them yielded
about a dozend.
Dilip Kumar writes:
> So n
On Fri, May 13, 2016 at 10:31 AM, Amit Kapila
wrote:
> Here I want to ask base rels which are plain rels?
>
> It might be that I am missing something, but if we debug the serial plan
> for original query [1] for which this issue is reported, we have noticed
> that PlaceHolderVars that contain sub
On Fri, May 13, 2016 at 9:43 AM, Amit Kapila
wrote:
>
> On Thu, May 12, 2016 at 11:37 PM, Tom Lane wrote:
> >
> > Robert Haas writes:
> > >> Target list for a relation, you mean? See relation.h:
> > >>
> > >> * reltarget - Default Path output tlist for this rel; normally
contains
> > >> *
On Thu, May 12, 2016 at 11:37 PM, Tom Lane wrote:
>
> Robert Haas writes:
> >> Target list for a relation, you mean? See relation.h:
> >>
> >> * reltarget - Default Path output tlist for this rel; normally
contains
> >> * Var and PlaceHolderVar nodes for the values we need
Robert Haas writes:
>> Target list for a relation, you mean? See relation.h:
>>
>> * reltarget - Default Path output tlist for this rel; normally contains
>> * Var and PlaceHolderVar nodes for the values we need to
>> * output from this relation.
>> *
On Thu, May 12, 2016 at 11:48 AM, Tom Lane wrote:
> Robert Haas writes:
>> I could be wrong, but I thought that the target list for an expression
>> would always contain only Vars at this stage. Non-default tlists get
>> injected at the end of scan/join planning. Am I wrong?
>
> Target list for
Robert Haas writes:
> I could be wrong, but I thought that the target list for an expression
> would always contain only Vars at this stage. Non-default tlists get
> injected at the end of scan/join planning. Am I wrong?
Target list for a relation, you mean? See relation.h:
* reltarget
On Thu, May 12, 2016 at 7:46 AM, Amit Kapila wrote:
> On further analysis, I think I know what is going on in the original bug
> report. We add the Vars (build_base_rel_tlists) and PlaceholderVars
> (add_placeholders_to_base_rels()) to each relations (RelOptInfo) target
> during qurey_planner and
On Sat, May 7, 2016 at 6:37 PM, Amit Kapila wrote:
>
> On Fri, May 6, 2016 at 8:45 AM, Tom Lane wrote:
> >
> > Andreas Seltenreich writes:
> > > when fuzz testing master as of c1543a8, parallel workers trigger the
> > > following assertion in ExecInitSubPlan every couple hours.
> > > TRAP: F
On Fri, May 6, 2016 at 8:45 AM, Tom Lane wrote:
>
> Andreas Seltenreich writes:
> > when fuzz testing master as of c1543a8, parallel workers trigger the
> > following assertion in ExecInitSubPlan every couple hours.
> > TRAP: FailedAssertion("!(list != ((List *) ((void *)0)))", File:
"list.c"
Andreas Seltenreich writes:
> when fuzz testing master as of c1543a8, parallel workers trigger the
> following assertion in ExecInitSubPlan every couple hours.
> TRAP: FailedAssertion("!(list != ((List *) ((void *)0)))", File:
> "list.c", Line: 390)
> Sample backtraces of a worker and leader
Hi,
when fuzz testing master as of c1543a8, parallel workers trigger the
following assertion in ExecInitSubPlan every couple hours.
TRAP: FailedAssertion("!(list != ((List *) ((void *)0)))", File: "list.c",
Line: 390)
Sample backtraces of a worker and leader below, plan of leader attached.
24 matches
Mail list logo
