On 16-03-2015 PM 04:14, Amit Kapila wrote:
> On Mon, Mar 16, 2015 at 9:40 AM, Amit Langote <langote_amit...@lab.ntt.co.jp>
> wrote:
>> Or if the just-detached queue happens to be the last one, we'll make
>> shm_mq_receive() to read from a potentially already-detached queue in the
>> immediately next iteration.
>
> Won't the last queue case already handled by below code:
> else
> {
> --funnel->nqueues;
> if (funnel->nqueues == 0)
> {
> if (done != NULL)
> *done = true;
> return NULL;
> }
>
Actually I meant "currently the last" or:
funnel->nextqueue == funnel->nqueue - 1
So the code you quote would only take care of subset of the cases.
Imagine funnel->nqueues going down from 5 to 3 in successive iterations while
funnel->nextqueue remains set to 4 (which would have been the "currently last"
when funnel->nqueues was 5).
>> I can't seem to really figure out the other problem of waiting forever in
>> WaitLatch()
>>
>
> The reason seems that for certain scenarios, the way we set the latch before
> exiting needs some more thought. Currently we are setting the latch in
> HandleParallelMessageInterrupt(), that doesn't seem to be sufficient.
>
How about shm_mq_detach() called from ParallelQueryMain() right after
exec_parallel_stmt() returns? Doesn't that do the SetLatch() that needs to be
done by a worker?
Thanks,
Amit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
