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. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
