Re: Quorum commit for multiple synchronous replication.
Michael Paquier <michael.paquier@gmail.com>
From: Michael Paquier <michael.paquier@gmail.com>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Petr Jelinek <petr@2ndquadrant.com>, Vik Fearing <vik@2ndquadrant.fr>, Simon Riggs <simon@2ndquadrant.com>, Josh Berkus <josh@agliodbs.com>, Fujii Masao <masao.fujii@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2016-10-11T09:10:18Z
Lists: 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
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Set the priorities of all quorum synchronous standbys to 1.
- 346199dcab4c 10.0 landed
-
Improve documentation and comment for quorum-based sync replication.
- a790ed9f69ef 10.0 landed