Re: Quorum commit for multiple synchronous replication. - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Quorum commit for multiple synchronous replication.
Date
Msg-id CAB7nPqTPMoEnt=YSBMFLmdNRvW+MJiuK+JFSG--xLv499Y-cGA@mail.gmail.com
Whole thread Raw
In response to Re: Quorum commit for multiple synchronous replication.  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: Quorum commit for multiple synchronous replication.  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
On Tue, Oct 11, 2016 at 4:18 PM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>> You may want to add an assert in
>> SyncRepGetSyncStandbysPriority and SyncRepGetSyncStandbysQuorum to be
>> sure that they are getting called for the correct method.
>> +   /* Sort each array in descending order to get 'pos' newest element */
>> +   qsort(write_array, len, sizeof(XLogRecPtr), cmp_lsn);
>> +   qsort(flush_array, len, sizeof(XLogRecPtr), cmp_lsn);
>> +   qsort(apply_array, len, sizeof(XLogRecPtr), cmp_lsn);
>> There is no need to reorder things again and to use arrays, you can
>> choose the newest LSNs when scanning the WalSnd entries.
>
> I considered it that but it depends on performance.
> Current patch avoids O(N*M).

I am surprised by this statement. You would have O(N) by just
discarding the oldest LSN values while holding the spinlock of each
WAL sender. What SyncRepGetNNewestSyncRecPtr looks for are just the
newest apply, write and flush positions.
-- 
Michael



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: memory leak in e94568ecc10 (pre-reading in external sort)
Next
From: Michael Paquier
Date:
Subject: Re: Quorum commit for multiple synchronous replication.