Re: Wait for parallel workers to attach
От | Robert Haas |
---|---|
Тема | Re: Wait for parallel workers to attach |
Дата | |
Msg-id | CA+TgmoZD2RmWYTxEOa69yqTwF419HWeg5bkNu5_UFJc9O7reLg@mail.gmail.com обсуждение исходный текст |
Ответ на | Wait for parallel workers to attach (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: Wait for parallel workers to attach
|
Список | pgsql-hackers |
On Sat, Jan 27, 2018 at 3:14 AM, Amit Kapila <amit.kapila16@gmail.com> wrote: > During the recent development of parallel operation (parallel create > index)[1], a need has been arised for $SUBJECT. The idea is to allow > leader backend to rely on number of workers that are successfully > started. This API allows leader to wait for all the workers to start > or fail even if one of the workers fails to attach. We consider > workers started/attached once they are attached to error queue. This > will ensure that any error after the workers are attached won't be > silently ignored by leader. known_started_workers looks a lot like any_message_received. Perhaps any_message_received should be renamed to known_started_workers and reused here. After all, if we know that a worker was started, there's no need for WaitForParallelWorkersToFinish to again call GetBackgroundWorkerPid() for it. I think that you shouldn't need the 10ms delay loop; waiting forever should work. If a work fails to start, the postmaster should send SIGUSR1 which should set our latch. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: