| From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
|---|---|
| To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: select_parallel test failure: gather sometimes losing tuples (maybe during rescans)? |
| Date: | 2018-03-04 03:37:01 |
| Message-ID: | CAEepm=1=+yxVLw-yX7jP1Jc7Z8a-mW_xNBPAjRBKRwk+ZJ4mYw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, Mar 4, 2018 at 4:17 PM, Tomas Vondra
<tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
> On 03/04/2018 04:11 AM, Thomas Munro wrote:
>> On Sun, Mar 4, 2018 at 4:07 PM, Tomas Vondra
>> <tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
>>> ! ERROR: lost connection to parallel worker
>>
>> That sounds like the new defences from 2badb5afb89cd569500ef7c3b23c7a9d11718f2f.
>
> Yeah. But I wonder why the worker fails at all, or how to find that.
Could it be that a concurrency bug causes tuples to be lost on the
tuple queue, and also sometimes causes X (terminate) messages to be
lost from the error queue, so that the worker appears to go away
unexpectedly?
--
Thomas Munro
http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2018-03-04 04:04:41 | Re: Rewriting the test of pg_upgrade as a TAP test - take two |
| Previous Message | Tomas Vondra | 2018-03-04 03:17:38 | Re: select_parallel test failure: gather sometimes losing tuples (maybe during rescans)? |