Re: [HACKERS] Parallel Hash take II

On 2017-11-30 14:17:51 +1300, Thomas Munro wrote:
> On Mon, Nov 27, 2017 at 10:25 PM, Thomas Munro
> <thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> > On Thu, Nov 23, 2017 at 12:36 AM, Thomas Munro
> > <thomas(dot)munro(at)enterprisedb(dot)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.

Played some with this, and confirmed that that case
works. Pushed. Interestingly my first few experiments with delaying the
master using pg_usleep() were *not* successful because the leader gets
signalled by the workers successfully having started, interrupting the
sleep...

I've not made any meaningful changes, there was a * missing in an empty
comment line, and I think I've added a single comma.

I do wonder if it's maybe worth adding a single graf about error
handling to the intro? It may not be obvious that this requires
installing a hook calling detach.

- Andres