Re: Parallel Seq Scan

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Parallel Seq Scan
Дата
Msg-id CAA4eK1LTt9VoBfNQxs-yrQ6ABcv4WOtZ6qP71dpE3cX2rAxY-w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Parallel Seq Scan  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Parallel Seq Scan  (Robert Haas <robertmhaas@gmail.com>)
Re: Parallel Seq Scan  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Wed, Mar 18, 2015 at 9:14 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Wed, Mar 18, 2015 at 2:22 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > It didn't fix the problem.  IIUC, you have done this to ensure that
> > if worker is not already started, then update it's pid, so that we
> > can get the required status in WaitForBackgroundWorkerShutdown().
> > As this is a timing issue, it can so happen that before Postmaster
> > gets a chance to report the pid, backend has already started waiting
> > on WaitLatch().
>
> I think I figured out the problem.  That fix only helps in the case
> where the postmaster noticed the new registration previously but
> didn't start the worker, and then later notices the termination.
> What's much more likely to happen is that the worker is started and
> terminated so quickly that both happen before we create a
> RegisteredBgWorker for it.  The attached patch fixes that case, too.
>

Patch fixes the problem and now for Rescan, we don't need to Wait
for workers to finish.

> Assuming this actually fixes the problem, I think we should back-patch
> it into 9.4.

+1


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

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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Table-level log_autovacuum_min_duration
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: deparsing utility commands