Re: Quorum commit for multiple synchronous replication.
От | Michael Paquier |
---|---|
Тема | Re: Quorum commit for multiple synchronous replication. |
Дата | |
Msg-id | CAB7nPqR53QAC332NsCfy1b1QpBUuWf8FuvsAf9y42_v25n3sbA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Quorum commit for multiple synchronous replication. (Michael Paquier <michael.paquier@gmail.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: