Re: Support for N synchronous standby servers - take 2 - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: Support for N synchronous standby servers - take 2
Date
Msg-id CAD21AoA5SQ7RS32UB3P1YOzJ=UECQHXK5-pRj4rnN07MkONrvg@mail.gmail.com
Whole thread Raw
In response to Re: Support for N synchronous standby servers - take 2  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-hackers
On Fri, Apr 8, 2016 at 4:50 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Fri, Apr 8, 2016 at 2:26 PM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
>> On Thu, Apr 7, 2016 at 11:43 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
>>> On Wed, Apr 6, 2016 at 5:04 PM, Michael Paquier
>>> <michael.paquier@gmail.com> wrote:
>>>> On Wed, Apr 6, 2016 at 4:08 PM, Michael Paquier
>>>> <michael.paquier@gmail.com> wrote:
>>>>> Here are few things I have noticed:
>>>>> +   for (i = 0; i < max_wal_senders; i++)
>>>>> +   {
>>>>> +       walsnd = &WalSndCtl->walsnds[i];
>>>>> No volatile pointer to prevent code reordering?
>>>>>
>>>>>   */
>>>>>  typedef struct WalSnd
>>>>>  {
>>>>> +   int     slotno;         /* index of this slot in WalSnd array */
>>>>>     pid_t       pid;            /* this walsender's process id, or 0 */
>>>>> slotno is used nowhere.
>>>>>
>>>>> I'll grab the tests and look at them.
>>>>
>>>> So I had a look at those tests and finished with the attached:
>>>> - patch 1 adds a reload routine to PostgresNode
>>>> - patch 2 the list of tests.
>>>
>>> Thanks for updating the patches!
>>>
>>> Attached is the refactored version of the patch.
>>
>> Thanks. This looks good to me.
>>
>> .gitattributes complains a bit:
>> $ git diff n_sync --check
>> src/test/recovery/t/007_sync_rep.pl:22: trailing whitespace.
>> +       $self->reload;
>
> Thanks for the review! I've finally pushed the patch.
>

Thank you!

Regards,

--
Masahiko Sawada



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Support for N synchronous standby servers - take 2
Next
From: Michael Paquier
Date:
Subject: Re: PATCH: pg_restore parallel-execution-deadlock issue