> On Thu, Oct 13, 2005 at 10:53:51AM -0700, Chris Travers wrote: > > Now, what about PgPool as a multimaster sync replication solution? Sure > > it is statement level.... But is there any reason why you cannot have > > multiple PgPool instances running against a number of DB servers? > > Well, to begin with, you have a serious race condition: > > pgpool begins T1 on M1 and M2. > Someone logs into M2 and does some work in T2. > M1 completes the work of T1. > M2 completes the work of T2. > pgpool issues COMMIT. > M1 replies with the COMMIT. > M2 detects a deadlock when T2 tries to COMMIT. > > Now what? There's nothing to prevent this in the system, as near as > I can see, so it's just not bullet proof enough for the cases where > people really, really need only five minutes of down time a year. If > you _really_ needed that, you'd be willing (and able) to pay the > costs. Of course, we can do what we can to make those costs go down. > :-> But they're not that low yet. Why pgpool should bother? pgpool supposes every transaction should go through pgpool. Your example sounds like someone logs into M2 and tries to shut down it. > Also, there is still (or was last I checked) a limitation on the > number of machines pgpool could address, and there are some stability > and reliability issues we've seen. It's a great piece of code, don't > get me wrong; but it's not stable enough yet to bet millions of > dollars on. I don't know what you kind of problem you are talking about, but... If you find problems, please post it to pgpool-general and let's solve it. That's the open source way. -- SRA OSS, Inc. Japan Tatsuo Ishii > ObNit: ORAC isn't really synchronous; it just looks that way. > > > This is multimaster async replication. But it can be further broken > > down into four types: > > Sure; I think you could break it even smaller sub-types, if you > worked at it, too. For example, an async system that tolerates > farily brief interruptions in two-way communications is very > different from the one where your sales force (or your Palm) shows up > after a week and dumps a whole bunch of new conflicts on your lap. > This second case is something Slony wouldn't tolerate; but I think a > relatively-high availability would probably work with some multi-way > conflict resolution, if someone were willing to build it. That > wasn't the itch Afilias needed scratching, because of the kinds of > problems we have to solve (to begin with, exactly one person may be > the registrant of record of a domain name at any one time, so > conflict resolution is just not allowed in our problem set: we have > to maintain global uniqueness). But we did have some discussions > about how one might file the corners of the hole to make it square > enough for the peg. I think it's possible, if someone volunteers to > do the work (maybe in a sub-project, maybe as a co-operative > project). I don't have the problem, so I can't justify the staff > time. So if someone _else_ has the problem, maybe s/he can. > > A > > -- > Andrew Sullivan | ajs@xxxxxxxxxxxxxxx > I remember when computers were frustrating because they *did* exactly what > you told them to. That actually seems sort of quaint now. > --J.D. Baldwin > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Have you searched our list archives? > > http://archives.postgresql.org > ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your message can get through to the mailing list cleanly
