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-04T04:40:38Z
Lists: pgsql-hackers 
On Sun, Mar 4, 2018 at 4:37 PM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> 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?

Could shm_mq_detach_internal() need a pg_write_barrier() before it
writes mq_detached = true, to make sure that anyone who observes that
can also see the most recent increase of mq_bytes_written?

-- 
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.