On Fri, Mar 13, 2015 at 11:03 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> On Fri, Mar 13, 2015 at 7:15 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>>
>> On Fri, Mar 13, 2015 at 7:01 AM, Amit Kapila <amit.kapila16@gmail.com>
>> wrote:
>> > I think this can happen if funnel->nextqueue is greater than
>> > funnel->nqueues.
>> > Please see if attached patch fixes the issue, else could you share the
>> > scenario in more detail where you hit this issue.
>>
>> Speaking as the guy who wrote the first version of that code...
>>
>> I don't think this is the right fix; the point of that code is to
>> remove a tuple queue from the funnel when it gets detached, which is a
>> correct thing to want to do. funnel->nextqueue should always be less
>> than funnel->nqueues; how is that failing to be the case here?
>>
>
> I could not reproduce the issue, neither the exact scenario is
> mentioned in mail. However what I think can lead to funnel->nextqueue
> greater than funnel->nqueues is something like below:
>
> Assume 5 queues, so value of funnel->nqueues will be 5 and
> assume value of funnel->nextqueue is 2, so now let us say 4 workers
> got detached one-by-one, so for such a case it will always go in else loop
> and will never change funnel->nextqueue whereas value of funnel->nqueues
> will become 1.
>
> Am I missing something?
>
Sorry, I did not mention the exact example I'd used but I thought it
was just any arbitrary example:
CREATE TABLE t1(c1, c2) SELECT g1, repeat('x', 5) FROM
generate_series(1, 10000000) g;
CREATE TABLE t2(c1, c2) SELECT g1, repeat('x', 5) FROM
generate_series(1, 1000000) g;
SELECT count(*) FROM t1 JOIN t2 ON t1.c1 = t2.c1 AND t1.c1 BETWEEN 100 AND 200;
The observed behavior included a hang or segfault arbitrarily (that's
why I guessed it may be arbitrariness of sequence of detachment of
workers).
Changed parameters to cause plan to include a Funnel:
parallel_seqscan_degree = 8
cpu_tuple_communication_cost = 0.01/0.001
Thanks,
Amit