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