Re: Parallel Seq Scan

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Parallel Seq Scan
Дата
Msg-id CAA4eK1LnAGH7CfsOAsaG5H+BEG=GtOMTGSk9GWAGqu=1FLYHEg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Parallel Seq Scan  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Parallel Seq Scan  (Amit Langote <amitlangote09@gmail.com>)
Re: Parallel Seq Scan  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Список pgsql-hackers
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?

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: CATUPDATE confusion?
Следующее
От: Petr Jelinek
Дата:
Сообщение: Re: recovery_target_action doesn't work for anything but shutdown