Re: [HACKERS] Parallel Hash take II - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: [HACKERS] Parallel Hash take II
Date
Msg-id CAEepm=2fvWkKMZ8yShRRR4nbg-mnWowWrqZKMBJX7uVHqb+T6w@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Parallel Hash take II  (Thomas Munro <thomas.munro@enterprisedb.com>)
Responses Re: [HACKERS] Parallel Hash take II  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Mon, Nov 27, 2017 at 10:25 PM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> On Thu, Nov 23, 2017 at 12:36 AM, Thomas Munro
> <thomas.munro@enterprisedb.com> wrote:
>> Here's a new patch set with responses to the last batch of review comments.
>
> Rebased on top of the recent SGML->XML change.

Andres asked me off-list how I tested the barrier.c case where a
backend detaches, releasing other waiters.  There are special cases in
BarrierArriveAndWait() and BarrierDetach() for that to make sure that
the phase advances and waiters are released if they were only waiting
for this one backend to arrive, and that exactly one of them is
"elected" for any serial work.  Normally the last to arrive is elected
(see earlier discussion about why that's a good idea), but if the one
that would be last detaches instead of arriving then we'll have to
elect someone else.  Here is a throw-away test harness that can be
used to exercise that case.  CREATE EXTENSION test_barrier; SELECT
test_barrier_detach_releases(1);.  Adding a sleep before BarrierDetach
can be used to influence the race, and adding elog messages to
barrier.c can be used to see when the special path is taken.

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

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [HACKERS] CONNECTION LIMIT and Parallel Query don't play well together
Next
From: Amit Langote
Date:
Subject: Re: Use of uninitialized variables in ExecFindPartition() for parentpartition without leaves (HEAD only)