Re: [HACKERS] intermittent failures in Cygwin from select_parallel tests
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] intermittent failures in Cygwin from select_parallel tests |
Дата | |
Msg-id | CA+TgmoZdpDbNbPQ79mbm=a2_jGaC5JFF7pqiJ8997_SpUzC0GQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] intermittent failures in Cygwin from select_parallel tests (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] intermittent failures in Cygwin from select_parallel tests
|
Список | pgsql-hackers |
On Thu, Jun 15, 2017 at 5:16 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Thu, Jun 15, 2017 at 5:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> ... nodeGather cannot deem the query done until it's seen EOF on >>> each tuple queue, which it cannot see until each worker has attached >>> to and then detached from the associated shm_mq. > >> Oh. That's sad. It definitely has to wait for any tuple queues that >> have been attached to be detached, but it would be better if it didn't >> have to wait for processes that haven't even attached yet. > > Hm. We assume they attach before they start taking any of the query > work? Seems reasonable, and this would give us some chance of recovering > from worker fork failure. Yeah, something like that. I'm not sure exactly how to implement it, though. I think I intended for it to work that way all along, but the code's not there. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: