On Fri, Jun 3, 2016 at 11:13 PM, Robert Haas wrote:
>> I think the workers should stop processing tuples after the tuple queues got
>> detached. This will not only handle above situation gracefully, but will
>> allow to speed up the queries where Limit clause is present on
On Sat, Jun 4, 2016 at 2:57 AM, Amit Kapila wrote:
> In the above change, you are first adding bytes_written and then doing the
> SHM_MQ_DETACHED check, whereas other place the check is done first which
> seems to be right. I think it doesn't matter either way, but it is
On Sat, Jun 4, 2016 at 8:43 AM, Robert Haas wrote:
>
> On Thu, May 26, 2016 at 5:57 AM, Amit Kapila
wrote:
> >
> > I am able to reproduce the assertion (it occurs once in two to three
times,
> > but always at same place) you have reported upthread
On Thu, May 26, 2016 at 5:57 AM, Amit Kapila wrote:
> On Tue, May 24, 2016 at 6:36 PM, Andreas Seltenreich
> wrote:
>>
>>
>> Each of the sent plans was collected when a worker dumped core due to
>> the failed assertion. More core dumps than plans
On Thu, May 26, 2016 at 03:27:40PM +0530, Amit Kapila wrote:
> I think the workers should stop processing tuples after the tuple queues
> got detached. This will not only handle above situation gracefully, but
> will allow to speed up the queries where Limit clause is present on top of
> Gather
On Tue, May 24, 2016 at 6:36 PM, Andreas Seltenreich
wrote:
>
>
> Each of the sent plans was collected when a worker dumped core due to
> the failed assertion. More core dumps than plans were actually
> observed, since with this failed assertion, multiple workers usually
>
Amit Kapila writes:
> On Mon, May 23, 2016 at 4:48 PM, Andreas Seltenreich
> wrote:
>> plan6 corresponds to this query:
>>
> Are you sure that the core dumps you are seeing are due to plan6?
Each of the plans sent was harvested from a controlling process when the
above
On Mon, May 23, 2016 at 4:48 PM, Andreas Seltenreich
wrote:
>
> Amit Kapila writes:
>
> > Earlier problems were due to the reason that some unsafe/restricted
> > expressions were pushed below Gather node as part of target list
whereas in
> > the plan6, it seems some unsafe
Amit Kapila writes:
> Earlier problems were due to the reason that some unsafe/restricted
> expressions were pushed below Gather node as part of target list whereas in
> the plan6, it seems some unsafe node is pushed below Gather node. It will
> be helpful if you can share the offending query?
On Mon, May 23, 2016 at 2:19 PM, Andreas Seltenreich
wrote:
>
> I wrote:
> >> There's another class of parallel worker core dumps when testing master
> >> with sqlsmith. In these cases, the following assertion fails for all
> >> workers simulataneously:
> >>
> >> TRAP:
I wrote:
>> There's another class of parallel worker core dumps when testing master
>> with sqlsmith. In these cases, the following assertion fails for all
>> workers simulataneously:
>>
>> TRAP: FailedAssertion("!(mqh->mqh_partial_bytes <= nbytes)", File:
>> "shm_mq.c", Line: 386)
>
> I no
I wrote:
> There's another class of parallel worker core dumps when testing master
> with sqlsmith. In these cases, the following assertion fails for all
> workers simulataneously:
>
> TRAP: FailedAssertion("!(mqh->mqh_partial_bytes <= nbytes)", File:
> "shm_mq.c", Line: 386)
I no longer
There's another class of parallel worker core dumps when testing master
with sqlsmith. In these cases, the following assertion fails for all
workers simulataneously:
TRAP: FailedAssertion("!(mqh->mqh_partial_bytes <= nbytes)", File: "shm_mq.c",
Line: 386)
The backtraces of the controlling
13 matches
Mail list logo