On Tue, Oct 11, 2016 at 6:08 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> 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.
Bah, stupid. I just missed the point with 'pos'. Now I see the trick.
--
Michael
