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

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 04:40:38
Message-ID: CAEepm=1323zKD-Wx5Psg5NhvOQT0ObaewugZVPE+cFt3Qew7zw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Mar 4, 2018 at 4:37 PM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Charles Cui 2018-03-04 05:00:22 Re: GSOC 2018 ideas
Previous Message Andrew Dunstan 2018-03-04 04:04:41 Re: Rewriting the test of pg_upgrade as a TAP test - take two