Re: select_parallel test failure: gather sometimes losing tuples (maybe during rescans)?
Tomas Vondra <tomas.vondra@2ndquadrant.com>
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Andres Freund <andres@anarazel.de>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2018-03-04T03:17:38Z
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.vondra@2ndquadrant.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
Commits
-
shm_mq: Fix detach race condition.
- 42d7074ebb83 11.0 landed
-
shm_mq: Have the receiver set the sender's less frequently.
- 497171d3e2aa 11.0 cited
-
shm_mq: Reduce spinlock usage.
- 34db06ef9a1d 11.0 cited
-
Report an ERROR if a parallel worker fails to start properly.
- 2badb5afb89c 11.0 cited