Re: [HACKERS] Parallel Hash take II
От | Thomas Munro |
---|---|
Тема | Re: [HACKERS] Parallel Hash take II |
Дата | |
Msg-id | CAEepm=2fvWkKMZ8yShRRR4nbg-mnWowWrqZKMBJX7uVHqb+T6w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Parallel Hash take II (Thomas Munro <thomas.munro@enterprisedb.com>) |
Ответы |
Re: [HACKERS] Parallel Hash take II
|
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: