Re: intermittent failures in Cygwin from select_parallel tests

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

In response to

Responses

Browse pgsql-hackers by date

  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