| From: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
|---|---|
| To: | Thomas Munro <thomas(dot)munro(at)enterprisedb(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:17:38 |
| Message-ID: | 59c7178b-11a5-dfdc-b7e7-e5a92779e6b7@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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:
>> I've started "make check" with parallel_schedule tweaked to contain many
>> select_parallel runs, and so far I've seen a couple of failures like
>> this (about 10 failures out of 1500 runs):
>>
>> select count(*) from tenk1, tenk2 where tenk1.hundred > 1 and
>> tenk2.thousand=0;
>> ! ERROR: lost connection to parallel worker
>>
>> I have no idea why the worker fails (no segfaults in dmesg, nothing in
>> posgres log), or if it's related to the issue discussed here at all.
>
> That sounds like the new defences from 2badb5afb89cd569500ef7c3b23c7a9d11718f2f.
>
Yeah. But I wonder why the worker fails at all, or how to find that.
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2018-03-04 03:37:01 | Re: select_parallel test failure: gather sometimes losing tuples (maybe during rescans)? |
| Previous Message | Thomas Munro | 2018-03-04 03:11:52 | Re: select_parallel test failure: gather sometimes losing tuples (maybe during rescans)? |