Horton

Re: select_parallel test failure: gather sometimes losing tuples (maybe during rescans)?

Thomas Munro <thomas.munro@enterprisedb.com>

View thread View on postgr.es
From: Thomas Munro <thomas.munro@enterprisedb.com>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: Andres Freund <andres@anarazel.de>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2018-03-04T03:11:52Z
Lists: pgsql-hackers 
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.

-- 
Thomas Munro
http://www.enterprisedb.com

Commits

  1. shm_mq: Fix detach race condition.

  2. shm_mq: Have the receiver set the sender's less frequently.

  3. shm_mq: Reduce spinlock usage.

  4. Report an ERROR if a parallel worker fails to start properly.