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