On Tue, Oct 11, 2016 at 6:08 PM, Michael Paquier
<michael.paqu...@gmail.com> wrote:
> On Tue, Oct 11, 2016 at 4:18 PM, Masahiko Sawada <sawada.m...@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.

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to