| From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
|---|---|
| To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Petr Jelinek <petr(at)2ndquadrant(dot)com>, Vik Fearing <vik(at)2ndquadrant(dot)fr>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Quorum commit for multiple synchronous replication. |
| Date: | 2016-10-11 09:08:12 |
| Message-ID: | CAB7nPqTPMoEnt=YSBMFLmdNRvW+MJiuK+JFSG--xLv499Y-cGA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Oct 11, 2016 at 4:18 PM, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)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.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2016-10-11 09:10:18 | Re: Quorum commit for multiple synchronous replication. |
| Previous Message | Heikki Linnakangas | 2016-10-11 08:45:15 | Re: memory leak in e94568ecc10 (pre-reading in external sort) |