Re: [HACKERS] Support for N synchronous standby servers - take 2

Hello, Tue, Jul 7, 2015 at 02:56 AM, Josh Berkus wrote: > pro-JSON: > > * standard syntax which is recognizable to sysadmins and devops. > * can use JSON/JSONB functions with ALTER SYSTEM SET to easily make > additions/deletions from the synch rep config. > * can add group labels (see below)

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Tue, Jul 7, 2015 at 2:19 PM, Josh Berkus wrote: > On 07/06/2015 09:56 PM, Michael Paquier wrote: >> On Tue, Jul 7, 2015 at 12:51 PM, Josh Berkus wrote: >>> On 07/06/2015 06:40 PM, Michael Paquier wrote: On Tue, Jul 7, 2015 at 2:56 AM, Josh Berkus wrote: > pro-JSON: > > * stan

Re: [HACKERS] Support for N synchronous standby servers - take 2

Amit wrote: > What if we write the above as: > > remotes-1 (london_servers-2 [london1, london2, london3], nc_servers-1 > [nc1, nc2]) Yes this we can consider. Thanks, - Beena Emerson -- View this message in context: http://postgresql.nabble.com/Support-for-N-synchronous-standby-servers

Re: [HACKERS] Support for N synchronous standby servers - take 2

Josh Berkus wrote: > '{ "remotes" : { "london_servers" : { "quorum" : 2, "servers" : [ > "london1", "london2", "london3" ] }, "nc_servers" : { "quorum" : 1, > "servers" [ "nc1", "nc2" ] } }' > > This says: as the "remotes" group, synch with a quorum of 2 servers in > london and a quorum of 1

Re: [HACKERS] Support for N synchronous standby servers - take 2

On 07/06/2015 09:56 PM, Michael Paquier wrote: > On Tue, Jul 7, 2015 at 12:51 PM, Josh Berkus wrote: >> On 07/06/2015 06:40 PM, Michael Paquier wrote: >>> On Tue, Jul 7, 2015 at 2:56 AM, Josh Berkus wrote: pro-JSON: * standard syntax which is recognizable to sysadmins and devops. >

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Tue, Jul 7, 2015 at 12:51 PM, Josh Berkus wrote: > On 07/06/2015 06:40 PM, Michael Paquier wrote: >> On Tue, Jul 7, 2015 at 2:56 AM, Josh Berkus wrote: >>> pro-JSON: >>> >>> * standard syntax which is recognizable to sysadmins and devops. >>> * can use JSON/JSONB functions with ALTER SYSTEM SE

Re: [HACKERS] Support for N synchronous standby servers - take 2

On 07/06/2015 06:40 PM, Michael Paquier wrote: > On Tue, Jul 7, 2015 at 2:56 AM, Josh Berkus wrote: >> pro-JSON: >> >> * standard syntax which is recognizable to sysadmins and devops. >> * can use JSON/JSONB functions with ALTER SYSTEM SET to easily make >> additions/deletions from the synch rep c

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Tue, Jul 7, 2015 at 2:56 AM, Josh Berkus wrote: > pro-JSON: > > * standard syntax which is recognizable to sysadmins and devops. > * can use JSON/JSONB functions with ALTER SYSTEM SET to easily make > additions/deletions from the synch rep config. > * can add group labels (see below) If we go

Re: [HACKERS] Support for N synchronous standby servers - take 2

On 2015-07-07 AM 02:56, Josh Berkus wrote: > > Re: group labels: I see a lot of value in being able to add names to > quorum groups. Think about how this will be represented in system > views; it will be difficult to show sync status of any quorum group in > any meaningful way if the group has no

Re: [HACKERS] Support for N synchronous standby servers - take 2

On 07/06/2015 10:03 AM, Sawada Masahiko wrote: >> > The setting that you need is 1(1[A, C], 1[B, C]) in Michael's proposed >> > grammer. >> > > If we set the remote disaster recovery site up as synch replica, we > would get some big latencies even though we use quorum commit. > So I think this cas

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Thu, Jul 2, 2015 at 9:31 PM, Fujii Masao wrote: > On Thu, Jul 2, 2015 at 5:44 PM, Beena Emerson wrote: >> Hello, >> There has been a lot of discussion. It has become a bit confusing. >> I am summarizing my understanding of the discussion till now. >> Kindly let me know if I missed anything imp

Re: [HACKERS] Support for N synchronous standby servers - take 2

Hello, This has been registered in the next 2015-09 CF since majority are in favor of adding this multiple sync replication feature (with quorum/priority). New patch will be submitted once we have reached a consensus on the design. -- Beena Emerson

Re: [HACKERS] Support for N synchronous standby servers - take 2

Josh Berkus wrote: > > Say you take this case: > > "2" : { "local_replica", "london_server", "nyc_server" } > > ... which should ensure that any data which is replicated is replicated > to at least two places, so that even if you lose the entire local > datacenter, you have the data on at least

Re: [HACKERS] Support for N synchronous standby servers - take 2

On 2015-07-02 11:50:44 -0700, Josh Berkus wrote: > So there's two parts to this: > > 1. I need to ensure that data is replicated to X places. > > 2. I need to *know* which places data was synchronously replicated to > when the master goes down. > > My entire point is that (1) alone is useless un

Re: [HACKERS] Support for N synchronous standby servers - take 2

On 07/02/2015 11:31 AM, Andres Freund wrote: > On 2015-07-02 11:10:27 -0700, Josh Berkus wrote: >> If we're always going to be polling the replicas for furthest ahead, >> then why bother implementing quorum synch at all? That's the basic >> question I'm asking. What does it buy us that we don't al

Re: [HACKERS] Support for N synchronous standby servers - take 2

On 2015-07-02 11:10:27 -0700, Josh Berkus wrote: > If we're always going to be polling the replicas for furthest ahead, > then why bother implementing quorum synch at all? That's the basic > question I'm asking. What does it buy us that we don't already have? What do those topic have to do with e

Re: [HACKERS] Support for N synchronous standby servers - take 2

On 07/01/2015 11:12 PM, Fujii Masao wrote: > I don't think this is good approach because there can be the case where > you need to promote even the standby server not having sync flag. > Please imagine the case where you have sync and async standby servers. > When the master goes down, the async st

Re: [HACKERS] Support for N synchronous standby servers - take 2

On 2 July 2015 at 09:44, Beena Emerson wrote: > I am not sure how combining both will work out. > Use cases needed. > Catalog Method: > Is it safe to assume we may not going ahead with the Catalog approach? > Yes -- Simon Riggshttp://www.2ndQuadrant.com/

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Thu, Jul 2, 2015 at 5:44 PM, Beena Emerson wrote: > Hello, > There has been a lot of discussion. It has become a bit confusing. > I am summarizing my understanding of the discussion till now. > Kindly let me know if I missed anything important. > > Backward compatibility: > We have to provide s

Re: [HACKERS] Support for N synchronous standby servers - take 2

Hello, There has been a lot of discussion. It has become a bit confusing. I am summarizing my understanding of the discussion till now. Kindly let me know if I missed anything important. Backward compatibility: We have to provide support for the current format and behavior for synchronous replica

Re: [HACKERS] Support for N synchronous standby servers - take 2

On 2015-07-02 PM 03:43, Beena Emerson wrote: > Amit wrote: > >> Does HA software determine a standby to promote based on replication >> progress >> or would things be reliable enough for it to infer one from the quorum >> setting >> specified in GUC (or wherever)? Is part of the job of this patc

Re: [HACKERS] Support for N synchronous standby servers - take 2

On 2015-07-02 PM 03:52, Michael Paquier wrote: > On Thu, Jul 2, 2015 at 3:29 PM, Amit Langote > wrote: >> On 2015-07-02 PM 03:12, Fujii Masao wrote: >>> >>> So I'm thinking that we basically need to check the progress on each >>> standby to choose new master. >>> >> >> Does HA software determine a

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Thu, Jul 2, 2015 at 3:29 PM, Amit Langote wrote: > On 2015-07-02 PM 03:12, Fujii Masao wrote: >> >> So I'm thinking that we basically need to check the progress on each >> standby to choose new master. >> > > Does HA software determine a standby to promote based on replication progress > or wou

Re: [HACKERS] Support for N synchronous standby servers - take 2

Amit wrote: > Does HA software determine a standby to promote based on replication > progress > or would things be reliable enough for it to infer one from the quorum > setting > specified in GUC (or wherever)? Is part of the job of this patch to make > the > latter possible? Just wondering or

Re: [HACKERS] Support for N synchronous standby servers - take 2

On 2015-07-02 PM 03:12, Fujii Masao wrote: > > So I'm thinking that we basically need to check the progress on each > standby to choose new master. > Does HA software determine a standby to promote based on replication progress or would things be reliable enough for it to infer one from the quor

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Thu, Jul 2, 2015 at 3:21 AM, Josh Berkus wrote: > All: > > Replying to multiple people below. > > On 07/01/2015 07:15 AM, Fujii Masao wrote: >> On Tue, Jun 30, 2015 at 2:40 AM, Josh Berkus wrote: >>> You're confusing two separate things. The primary manageability problem >>> has nothing to do

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Wed, Jul 1, 2015 at 11:58 PM, Sawada Masahiko wrote: > On Tue, Jun 30, 2015 at 2:40 AM, Josh Berkus wrote: >> >> BTW, ALTER SYSTEM is a strong reason to use JSON for the synch rep GUC >> (assuming it's one parameter) instead of some custom syntax. If it's >> JSON, we can validate it in psql, wh

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Wed, Jul 1, 2015 at 11:45 PM, Peter Eisentraut wrote: > On 6/26/15 1:46 AM, Michael Paquier wrote: >> - k(elt1,elt2,eltN) means that we need for the k elements in the set >> to return true (aka commit confirmation). >> - k[elt1,elt2,eltN] means that we need for the first k elements in the >> se

Re: [HACKERS] Support for N synchronous standby servers - take 2

All: Replying to multiple people below. On 07/01/2015 07:15 AM, Fujii Masao wrote: > On Tue, Jun 30, 2015 at 2:40 AM, Josh Berkus wrote: >> You're confusing two separate things. The primary manageability problem >> has nothing to do with altering the parameter. The main problem is: if >> there

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Tue, Jun 30, 2015 at 2:40 AM, Josh Berkus wrote: > On 06/29/2015 01:01 AM, Michael Paquier wrote: > > You're confusing two separate things. The primary manageability problem > has nothing to do with altering the parameter. The main problem is: if > there is more than one synch candidate, how

Re: [HACKERS] Support for N synchronous standby servers - take 2

On 6/26/15 1:12 PM, Josh Berkus wrote: > If we're going to do quorum, multi-set synchrep, then we need to have a > real management interface. Like, we really ought to have a system > catalog and some built in functions to manage this instead, e.g. > > pg_add_synch_set(set_name NAME, quorum INT, s

Re: [HACKERS] Support for N synchronous standby servers - take 2

On 7/1/15 10:15 AM, Fujii Masao wrote: > One approach to address this problem is to introduce something like unlogged > system catalog. I'm not sure if that causes another big problem, though... Yeah, like the data disappearing after a crash. ;-) -- Sent via pgsql-hackers mailing list (pgsql-h

Re: [HACKERS] Support for N synchronous standby servers - take 2

On 6/26/15 2:53 PM, Josh Berkus wrote: > 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? Does JSON have a natural syntax for a set without order? -- Sent via pgsql-hac

Re: [HACKERS] Support for N synchronous standby servers - take 2

On 6/26/15 1:46 AM, Michael Paquier wrote: > - k(elt1,elt2,eltN) means that we need for the k elements in the set > to return true (aka commit confirmation). > - k[elt1,elt2,eltN] means that we need for the first k elements in the > set to return true. I think the difference between (...) and [...

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Tue, Jun 30, 2015 at 2:40 AM, Josh Berkus wrote: > On 06/29/2015 01:01 AM, Michael Paquier wrote: >> On Mon, Jun 29, 2015 at 4:20 AM, Josh Berkus wrote: > >>> Right. Well, another reason we should be using a system catalog and not >>> a single GUC ... The problem by using system catalog to c

Re: [HACKERS] Support for N synchronous standby servers - take 2

On 06/29/2015 01:01 AM, Michael Paquier wrote: > On Mon, Jun 29, 2015 at 4:20 AM, Josh Berkus wrote: >> Right. Well, another reason we should be using a system catalog and not >> a single GUC ... > > I assume that this takes into account the fact that you will still > need a SIGHUP to reload pr

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Mon, Jun 29, 2015 at 4:20 AM, Josh Berkus wrote: > On 06/28/2015 04:36 AM, Sawada Masahiko wrote: >> On Sat, Jun 27, 2015 at 3:53 AM, Josh Berkus 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

Re: [HACKERS] Support for N synchronous standby servers - take 2

On 06/28/2015 04:36 AM, Sawada Masahiko wrote: > On Sat, Jun 27, 2015 at 3:53 AM, Josh Berkus 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 >>

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Sat, Jun 27, 2015 at 2:12 AM, Josh Berkus wrote: > Finally, while I'm raining on everyone's parade: the mechanism of > identifying synchronous replicas by setting the application_name on the > replica is confusing and error-prone; if we're building out synchronous > replication into a sophistic

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Sat, Jun 27, 2015 at 3:53 AM, Josh Berkus 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-

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Sun, Jun 28, 2015 at 5:52 PM, Sawada Masahiko wrote: > On Fri, Jun 26, 2015 at 2:46 PM, Michael Paquier > wrote: >> On Thu, Jun 25, 2015 at 8:32 PM, Simon Riggs wrote: >>> Let's start with a complex, fully described use case then work out how to >>> specify what we want. >> >> Well, one of th

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Fri, Jun 26, 2015 at 2:46 PM, Michael Paquier wrote: > On Thu, Jun 25, 2015 at 8:32 PM, Simon Riggs wrote: >> Let's start with a complex, fully described use case then work out how to >> specify what we want. > > Well, one of the most simple cases where quorum commit and this > feature would b

Re: [HACKERS] Support for N synchronous standby servers - take 2

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 rule

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Fri, Jun 26, 2015 at 1:12 PM, Josh Berkus wrote: > This really feels like we're going way beyond what we want a single > string GUC. I feel that this feature, as outlined, is a terrible hack > which we will regret supporting in the future. You're taking something > which was already a fast ha

Re: [HACKERS] Support for N synchronous standby servers - take 2

On 06/26/2015 09:42 AM, Robert Haas wrote: > On Fri, Jun 26, 2015 at 1:46 AM, Michael Paquier >> That's where the micro-language idea makes sense to use. For example, >> we can define a group using separators and like (elt1,...eltN) or >> [elt1,elt2,eltN]. Appending a number in front of a group is

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Fri, Jun 26, 2015 at 1:46 AM, Michael Paquier wrote: > On Thu, Jun 25, 2015 at 8:32 PM, Simon Riggs wrote: >> Let's start with a complex, fully described use case then work out how to >> specify what we want. > > Well, one of the most simple cases where quorum commit and this > feature would b

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Fri, Jun 26, 2015 at 5:04 PM, Amit Langote wrote: > > Hi, > > On 2015-06-25 PM 01:01, Michael Paquier wrote: >> On Thu, Jun 25, 2015 at 12:57 PM, Fujii Masao wrote: >>> On Thu, Jun 25, 2015 at 12:15 PM, Michael Paquier wrote: and that's actually equivalent to that in the grammar: 1(AA

Re: [HACKERS] Support for N synchronous standby servers - take 2

Hi, On 2015-06-25 PM 01:01, Michael Paquier wrote: > On Thu, Jun 25, 2015 at 12:57 PM, Fujii Masao wrote: >> On Thu, Jun 25, 2015 at 12:15 PM, Michael Paquier wrote: >>> and that's actually equivalent to that in >>> the grammar: 1(AAA,BBB,CCC). >> >> I don't think that they are the same. In the c

Re: [HACKERS] Support for N synchronous standby servers - take 2

On 2015-06-26 PM 02:59, Amit Langote wrote: > On 2015-06-26 AM 12:49, Sawada Masahiko wrote: >> >> For example, >> - s_s_name = '1(a, b), c, d' >> The priority of both 'a' and 'b' are 1, and 'c' is 2, 'd' is 3. >> i.g, 'b' and 'c' are potential sync node, and the quorum commit is >> enable only bet

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Fri, Jun 26, 2015 at 2:59 PM, Amit Langote wrote: > Do we really need to add a number like '1' in '1(a, b), c, d'? > The order of writing names already implies priorities like 2 & 3 for c & d, > respectively, like in your example. Having to write '1' for the group '(a, b)' > seems unnecessary, I

Re: [HACKERS] Support for N synchronous standby servers - take 2

Hi, On 2015-06-26 AM 12:49, Sawada Masahiko wrote: > On Thu, Jun 25, 2015 at 7:32 AM, Simon Riggs wrote: >> >> Let's start with a complex, fully described use case then work out how to >> specify what we want. >> >> I'm nervous of "it would be good ifs" because we do a ton of work only to >> fin

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Thu, Jun 25, 2015 at 8:32 PM, Simon Riggs wrote: > Let's start with a complex, fully described use case then work out how to > specify what we want. Well, one of the most simple cases where quorum commit and this feature would be useful for is that, with 2 data centers: - on center 1, master A

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Thu, Jun 25, 2015 at 7:32 AM, Simon Riggs wrote: > On 25 June 2015 at 05:01, Michael Paquier wrote: >> >> On Thu, Jun 25, 2015 at 12:57 PM, Fujii Masao wrote: >> > On Thu, Jun 25, 2015 at 12:15 PM, Michael Paquier wrote: >> >> and that's actually equivalent to that in >> >> the grammar: 1(AAA,

Re: [HACKERS] Support for N synchronous standby servers - take 2

On 25 June 2015 at 05:01, Michael Paquier wrote: > On Thu, Jun 25, 2015 at 12:57 PM, Fujii Masao wrote: > > On Thu, Jun 25, 2015 at 12:15 PM, Michael Paquier wrote: > >> and that's actually equivalent to that in > >> the grammar: 1(AAA,BBB,CCC). > > > > I don't think that they are the same. In th

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Thu, Jun 25, 2015 at 12:15 PM, Michael Paquier wrote: > On Wed, Jun 24, 2015 at 11:30 PM, Fujii Masao wrote: >> On Fri, May 15, 2015 at 9:18 PM, Michael Paquier >> wrote: >>> On Fri, May 15, 2015 at 8:55 PM, Beena Emerson >>> wrote: There was a discussion on support for N synchronous s

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Thu, Jun 25, 2015 at 12:57 PM, Fujii Masao wrote: > On Thu, Jun 25, 2015 at 12:15 PM, Michael Paquier wrote: >> and that's actually equivalent to that in >> the grammar: 1(AAA,BBB,CCC). > > I don't think that they are the same. In the case of 1(AAA,BBB,CCC), while > two servers AAA and BBB are r

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Wed, Jun 24, 2015 at 11:30 PM, Fujii Masao wrote: > On Fri, May 15, 2015 at 9:18 PM, Michael Paquier > wrote: >> On Fri, May 15, 2015 at 8:55 PM, Beena Emerson >> wrote: >>> There was a discussion on support for N synchronous standby servers started >>> by Michael. Refer >>> http://archives.

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Fri, May 15, 2015 at 9:18 PM, Michael Paquier wrote: > On Fri, May 15, 2015 at 8:55 PM, Beena Emerson > wrote: >> There was a discussion on support for N synchronous standby servers started >> by Michael. Refer >> http://archives.postgresql.org/message-id/cab7npqr9c84ig0zuvhmqamq53vqsd4rc82vy

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Mon, May 18, 2015 at 9:40 AM, Beena Emerson wrote: >> Er, I am not sure I follow here. The idea proposed was to define a >> string formatted with some infra-language within the existing GUC >> s_s_names. > > I am sorry, I misunderstood. I thought the "language" approach meant use of > hooks an

Re: [HACKERS] Support for N synchronous standby servers - take 2

Hello, > Er, I am not sure I follow here. The idea proposed was to define a > string formatted with some infra-language within the existing GUC > s_s_names. I am sorry, I misunderstood. I thought the "language" approach meant use of hooks and module. As you mentioned the first step would be t

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Mon, May 18, 2015 at 8:42 PM, Beena Emerson wrote: > Hello, > >> I don't think that this is going in the good direction, what was >> suggested mainly by Robert was to use a micro-language that would >> allow far more extensibility that what you are proposing. > > I agree, the micro-language wou

Re: [HACKERS] Support for N synchronous standby servers - take 2

> As proposed, this feature does not bring us really closer to quorum > commit, and AFAIK this is what we are more or less aiming at recalling > previous discussions. Particularly with the syntax proposed above, it > is not possible to do some OR conditions on subgroups of nodes, the > list of

Re: [HACKERS] Support for N synchronous standby servers - take 2

Hello, > I don't think that this is going in the good direction, what was > suggested mainly by Robert was to use a micro-language that would > allow far more extensibility that what you are proposing. I agree, the micro-language would give far more extensibility. However, as stated ibefore, t

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Sat, May 16, 2015 at 5:58 PM, Sawada Masahiko wrote: > The dedicated language for multiple sync replication would be more > extensibility as you said, but I think there are not a lot of user who > want to or should use this. > IMHO such a dedicated extensible feature could be extension module, >

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Fri, May 15, 2015 at 9:18 PM, Michael Paquier wrote: > On Fri, May 15, 2015 at 8:55 PM, Beena Emerson > wrote: >> There was a discussion on support for N synchronous standby servers started >> by Michael. Refer >> http://archives.postgresql.org/message-id/cab7npqr9c84ig0zuvhmqamq53vqsd4rc82vy

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Fri, May 15, 2015 at 8:55 PM, Beena Emerson wrote: > There was a discussion on support for N synchronous standby servers started > by Michael. Refer > http://archives.postgresql.org/message-id/cab7npqr9c84ig0zuvhmqamq53vqsd4rc82vyci4dr27pvof...@mail.gmail.com > . The use of hooks and dedicated

<    1   2   3   4