On Wed, Apr 6, 2016 at 5:01 PM, Kyotaro HORIGUCHI
<horiguchi.kyot...@lab.ntt.co.jp> wrote:
> At Wed, 6 Apr 2016 15:29:12 +0900, Fujii Masao <masao.fu...@gmail.com> wrote
> in <CAHGQGwHGQEwH2c9buiZ=G7Ko8PQYwiU7=nsdkvcjrkupsn8...@mail.gmail.com>
>> > @@ -640,6 +639,13 @@ SyncRepGetSyncStandbys(bool *am_sync)
>> > }
>> >
>> > /*
>> > + * The pending list contains eventually potentially-synchronized
>> > standbys
>> > + * and this walsender may be one of them. So once reset am_sync.
>> > + */
>> > + if (am_sync != NULL)
>> > + *am_sync = false;
>> > +
>> > + /*
>>
>> This code seems wrong in the case where this walsender is in the result list.
>> So I adopted another logic. Attached is the updated version of the patch.
>
> You must misread the patch. am_sync is originally set in the loop
> just after that for the case.
>
> ! while (priority <= lowest_priority)
> ! {
> ..
> ! for (cell = list_head(pending); cell != NULL; cell = next)
> ! {
> ...
> ! if (this_priority == priority)
> ! {
> ! result = lappend_int(result, i);
> ! if (am_sync != NULL && walsnd == MyWalSnd)
> ! *am_sync = true;
But if this walsender has the priority 1, *am_sync is set to true in
the first loop not the second one. No?
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
