On Tue, Oct 11, 2016 at 6:08 PM, Michael Paquier
> On Tue, Oct 11, 2016 at 4:18 PM, Masahiko Sawada <sawada.m...@gmail.com>
>>> 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.
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: