From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: intermittent failures in Cygwin from select_parallel tests |
Date: | 2017-06-15 21:50:06 |
Message-ID: | CA+TgmoZdpDbNbPQ79mbm=a2_jGaC5JFF7pqiJ8997_SpUzC0GQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jun 15, 2017 at 5:16 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Thu, Jun 15, 2017 at 5:06 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2017-06-15 22:06:43 | Re: subscription worker signalling wal writer too much |
Previous Message | Thomas Munro | 2017-06-15 21:42:38 | Re: Decimal64 and Decimal128 |