On Sat, Jun 27, 2015 at 3:53 AM, Josh Berkus <j...@agliodbs.com> wrote: > On 06/26/2015 11:32 AM, Robert Haas wrote: >> I think your proposal is worth considering, but you would need to fill >> in a lot more details and explain how it works in detail, rather than >> just via a set of example function calls. The GUC-based syntax >> proposal covers cases like multi-level rules and, now, prioritization, >> and it's not clear how those would be reflected in what you propose. > > So what I'm seeing from the current proposal is: > > 1. we have several defined synchronous sets > 2. each set requires a quorum of k (defined per set) > 3. within each set, replicas are arranged in priority order. > > One thing which the proposal does not implement is *names* for > synchronous sets. I would also suggest that if I lose this battle and > we decide to go with a single stringy GUC, that we at least use JSON > instead of defining our out, proprietary, syntax?
JSON would be more flexible for making synchronous set, but it will make us to change how to parse configuration file to enable a value contains newline. > Point 3. also seems kind of vaguely defined. Are we still relying on > the idea that multiple servers have the same application_name to make > them equal, and that anything else is a proritization? That is, if we have: Yep, I guess that the same application name servers have same priority, and the servers in same set have same priority. (The set means here that bunch of application name in GUC). > replica1: appname=group1 > replica2: appname=group2 > replica3: appname=group1 > replica4: appname=group2 > replica5: appname=group1 > replica6: appname=group2 > > And the definition: > > synchset: A > quorum: 2 > members: [ group1, group2 ] > > Then the desired behavior would be: we must get acks from at least 2 > servers in group1, but if group1 isn't responding, then from group2? In this case, If we want to use quorum commit (i.g., all replica have same priority), I guess that we must get ack from 2 *elements* in listed (both group1 and group2). If quorumm = 1, we must get ack from either group1 or group2. > What if *one* server in group1 responds? What do we do? Do we fail the > whole group and try for 2 out of 3 in group2? Or do we only need one in > group2? In which case, what prioritization is there? Who could > possibly use anything so complex? If some servers have same application name, the master server will get each different ack(write, flush LSN) from same application name servers. We can use the lowest LSN of them to release backend waiters, for more safety. But if only one server in group1 returns ack to the master server, and other two servers are not working, I guess the master server can use it because other servers is invalid server. That is, we must get ack at least 1 from each group1 and group2. > I'm personally not convinced that quorum and prioritization are > compatible. I suggest instead that quorum and prioritization should be > exclusive alternatives, that is that a synch set should be either a > quorum set (with all members as equals) or a prioritization set (if rep1 > fails, try rep2). I can imagine use cases for either mode, but not one > which would involve doing both together. > Yep, separating the GUC parameter between prioritization and quorum could be also good idea. Also I think that we must enable us to decide which server we should promote when the master server is down. Regards, -- Sawada Masahiko -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
