Re: [DOCS] [HACKERS] Replication documentation addition

> I don't think the PostgreSQL documentation should be > mentioning commercial solutions. I think maybe the PostgreSQL documentation should be careful about trying to list a "complete list" of commercial *or* free solutions. Instead linking to something on the main website or on techdocs that can

Re: [DOCS] [HACKERS] Replication documentation addition

Hi, Bruce Momjian wrote: I have updated the text. Please let me know what else I should change. I am unsure if I should be mentioning commercial PostgreSQL products in our documentation. I support your POV and vote for not including any pointers to commercial extensions in the official docu

Re: [HACKERS] Replication documentation addition

half Of Bruce Momjian > > > Sent: Tuesday, October 24, 2006 5:16 PM > > > To: Hannu Krosing > > > Cc: PostgreSQL-documentation; PostgreSQL-development > > > Subject: Re: [HACKERS] Replication documentation addition > > > > > > > >

Re: [DOCS] [HACKERS] Replication documentation addition

Hi, I also wrote Bruce about that. It happens that, if you 'freely advertise' commercial solutions (rather than they doing so by other vehicles) you will always happen to be an 'updater' to the docs if they change their product lines, if they change their business model, if and if. If you c

Re: [DOCS] [HACKERS] Replication documentation addition

On Oct 24, 2006, at 9:20 PM, Bruce Momjian wrote: Steve Atkins wrote: If we are to add them, I need to hear that from people who haven't worked in PostgreSQL commerical replication companies. I'm not coming to PostgreSQL for open source solutions. I'm coming to PostgreSQL for _good_ solution

Re: [DOCS] [HACKERS] Replication documentation addition

Steve Atkins wrote: > > If we are to add them, I need to hear that from people who haven't > > worked in PostgreSQL commerical replication companies. > > I'm not coming to PostgreSQL for open source solutions. I'm coming > to PostgreSQL for _good_ solutions. > > I want to see what solutions might

Re: [DOCS] [HACKERS] Replication documentation addition

On Oct 24, 2006, at 8:48 PM, Bruce Momjian wrote: Joshua D. Drake wrote: Josh Berkus wrote: Bruce, I have updated the text. Please let me know what else I should change. I am unsure if I should be mentioning commercial PostgreSQL products in our documentation. I think you should ment

Re: [DOCS] [HACKERS] Replication documentation addition

Joshua D. Drake wrote: > Josh Berkus wrote: > > Bruce, > > > >> I have updated the text. Please let me know what else I should change. > >> I am unsure if I should be mentioning commercial PostgreSQL products in > >> our documentation. > > > > I think you should mention the postgresql-only ones,

Re: [HACKERS] Replication documentation addition

Josh Berkus wrote: > Bruce, > >> I have updated the text. Please let me know what else I should change. >> I am unsure if I should be mentioning commercial PostgreSQL products in >> our documentation. > > I think you should mention the postgresql-only ones, but just briefly with a > link. Bizg

Re: [HACKERS] Replication documentation addition

Bruce, > I have updated the text.  Please let me know what else I should change. > I am unsure if I should be mentioning commercial PostgreSQL products in > our documentation. I think you should mention the postgresql-only ones, but just briefly with a link. Bizgres MPP, ExtenDB, uni/cluster, a

Re: [DOCS] [HACKERS] Replication documentation addition

Joshua D. Drake wrote: > > > Looking at that, I'm a) missing PgCluster and b) arguing that we have to > > admit that we simply can not 'list .. replication solutions ... and how > > to get them' because all of the solutions mentioned need quite some > > knowledge and require a more or less complex

Re: [HACKERS] Replication documentation addition

o:[EMAIL PROTECTED] On Behalf Of Bruce Momjian > > Sent: Tuesday, October 24, 2006 5:16 PM > > To: Hannu Krosing > > Cc: PostgreSQL-documentation; PostgreSQL-development > > Subject: Re: [HACKERS] Replication documentation addition > > > > > > OK, I ha

Re: [HACKERS] Replication documentation addition

Markus Schiltknecht wrote: > Looking at that, I'm a) missing PgCluster and b) arguing that we have to > admit that we simply can not 'list .. replication solutions ... and how > to get them' because all of the solutions mentioned need quite some > knowledge and require a more or less complex ins

Re: [HACKERS] Replication documentation addition

I have updated the text. Please let me know what else I should change. I am unsure if I should be mentioning commercial PostgreSQL products in our documentation. --- Hannu Krosing wrote: > ?hel kenal p?eval, T, 2006-10-24

Re: [HACKERS] Replication documentation addition

Bruce, > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Momjian > Sent: Tuesday, October 24, 2006 5:16 PM > To: Hannu Krosing > Cc: PostgreSQL-documentation; PostgreSQL-development > Subject: Re: [HACKERS] Replication d

Re: [DOCS] [HACKERS] Replication documentation addition

On Tue, 24 Oct 2006, Joshua D. Drake wrote: AFAIK Continuent's product fails that test... To my knowledge, p/cluster only works with PostgreSQL but I could be wrong. p/cluster was the old name for the PostgreSQL specific version. It's been rebranded as uni/cluster and they have versions f

Re: [HACKERS] Replication documentation addition

OK, I have updated the URL. Please let me know how you like it. --- Hannu Krosing wrote: > ?hel kenal p?eval, T, 2006-10-24 kell 00:20, kirjutas Bruce Momjian: > > Here is a new replication documentation section I want to a

Re: [DOCS] [HACKERS] Replication documentation addition

Jim C. Nasby wrote: > On Tue, Oct 24, 2006 at 03:33:03PM -0700, Joshua D. Drake wrote: >> Simon Riggs wrote: >>> On Tue, 2006-10-24 at 15:13 -0700, Joshua D. Drake wrote: >>> If it were me, I would say that the replication option has to be specific to PostgreSQL (e.g; cjdbc or synchronous

Re: [DOCS] [HACKERS] Replication documentation addition

On Tue, Oct 24, 2006 at 03:33:03PM -0700, Joshua D. Drake wrote: > Simon Riggs wrote: > > On Tue, 2006-10-24 at 15:13 -0700, Joshua D. Drake wrote: > > > >> If it were me, I would say that the replication option has to be > >> specific to PostgreSQL (e.g; cjdbc or synchronous jakarta pooling > >>

Re: [HACKERS] Replication documentation addition

On Mon, Oct 23, 2006 at 11:39:34PM -0400, Bruce Momjian wrote: > Query Broadcast Replication > --- > > This involves sending write queries to multiple servers. Read-only > queries can be sent to a single server because there is no need for all > servers to process it. Th

Re: [DOCS] [HACKERS] Replication documentation addition

Simon Riggs wrote: > On Tue, 2006-10-24 at 15:33 -0700, Joshua D. Drake wrote: >> Simon Riggs wrote: >>> On Tue, 2006-10-24 at 15:13 -0700, Joshua D. Drake wrote: >>> If it were me, I would say that the replication option has to be specific to PostgreSQL (e.g; cjdbc or synchronous jakarta

Re: [DOCS] [HACKERS] Replication documentation addition

On Tue, 2006-10-24 at 15:33 -0700, Joshua D. Drake wrote: > Simon Riggs wrote: > > On Tue, 2006-10-24 at 15:13 -0700, Joshua D. Drake wrote: > > > >> If it were me, I would say that the replication option has to be > >> specific to PostgreSQL (e.g; cjdbc or synchronous jakarta pooling > >> doesn't

Re: [DOCS] [HACKERS] Replication documentation addition

Simon Riggs wrote: > On Tue, 2006-10-24 at 15:13 -0700, Joshua D. Drake wrote: > >> If it were me, I would say that the replication option has to be >> specific to PostgreSQL (e.g; cjdbc or synchronous jakarta pooling >> doesn't go in). > > ...and how do you define PostgreSQL exactly? I replicat

Re: [DOCS] [HACKERS] Replication documentation addition

On Tue, 2006-10-24 at 15:13 -0700, Joshua D. Drake wrote: > If it were me, I would say that the replication option has to be > specific to PostgreSQL (e.g; cjdbc or synchronous jakarta pooling > doesn't go in). ...and how do you define PostgreSQL exactly? -- Simon Riggs Enterpr

Re: [DOCS] [HACKERS] Replication documentation addition

Simon Riggs wrote: > On Tue, 2006-10-24 at 12:34 -0700, Joshua D. Drake wrote: >>> Looking at that, I'm a) missing PgCluster and b) arguing that we have to >>> admit that we simply can not 'list .. replication solutions ... and how >>> to get them' because all of the solutions mentioned need quite

Re: [DOCS] [HACKERS] Replication documentation addition

On Tue, 2006-10-24 at 12:34 -0700, Joshua D. Drake wrote: > > Looking at that, I'm a) missing PgCluster and b) arguing that we have to > > admit that we simply can not 'list .. replication solutions ... and how > > to get them' because all of the solutions mentioned need quite some > > knowledge an

Re: [DOCS] [HACKERS] Replication documentation addition

> Looking at that, I'm a) missing PgCluster and b) arguing that we have to > admit that we simply can not 'list .. replication solutions ... and how > to get them' because all of the solutions mentioned need quite some > knowledge and require a more or less complex installation and > configuration

Re: [HACKERS] Replication documentation addition

Hello Josh, Josh Berkus wrote: Hmmm ... while the primer on different types of replication is fine, I think what users were really looking for is a listing of the different replication solutions which are available for PostgreSQL and how to get them. Well, let's see what we have: * Shared D

Re: [HACKERS] Replication documentation addition

Bruce, > Here is my first draft of a new replication section for our > documentation. I am looking for any comments. Hmmm ... while the primer on different types of replication is fine, I think what users were really looking for is a listing of the different replication solutions which are ava

Re: [HACKERS] Replication documentation addition

Hannu Krosing wrote: I think the "official" term for this kind of "replication" is Shared-Nothing Clustering. Well, that's just another distinction for clusters. Most of the time it's between Shared-Disk vs. Shared-Nothing. You could also see the very Big Irons as a Shared-Everything Cluster.

Re: [HACKERS] Replication documentation addition

Ühel kenal päeval, T, 2006-10-24 kell 00:20, kirjutas Bruce Momjian: > Here is a new replication documentation section I want to add for 8.2: > > ftp://momjian.us/pub/postgresql/mypatches/replication This is how data partitioning is currently described there > Data Partitioning > -

[HACKERS] Replication documentation addition

Here is a new replication documentation section I want to add for 8.2: ftp://momjian.us/pub/postgresql/mypatches/replication Comments welcomed. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your back

[HACKERS] Replication documentation addition

Here is my first draft of a new replication section for our documentation. I am looking for any comments. --- Replication === Database replication allows multiple computers to work together, making them appear as a

[HACKERS] Replication documentation

FYI, I have started working on a replication section for our 8.2 documentation. I will post a draft copy as soon as I finish. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +

Re: [HACKERS] Replication hooks discussion

On Friday 29 September 2006 20:02, Andrew Sullivan wrote: > At the beginning of the month, in > , > I said that I'd be willing to try to do any sort of co-ordination, > document writing, &c. for a project that might define common ba

[HACKERS] Replication hooks discussion

Hello, At the beginning of the month, in , I said that I'd be willing to try to do any sort of co-ordination, document writing, &c. for a project that might define common back-end resources necessary for the various kinds of replic

Re: [HACKERS] Replication

On Fri, 2006-08-25 at 11:23 +0200, Markus Schiltknecht wrote: > Jeff Davis wrote: > > Which doesn't work very well in the case of two groups of servers set up > > in two physical locations. I can see two possibilities: > > (1) You require a quorum to be effective, in which case your cluster of > >

Re: [HACKERS] Replication

Jeff Davis wrote: Which doesn't work very well in the case of two groups of servers set up in two physical locations. I can see two possibilities: (1) You require a quorum to be effective, in which case your cluster of databases is only as reliable as the location which holds more servers. (2) Yo

Re: [HACKERS] Replication

On Thu, 2006-08-24 at 11:18 +0200, Markus Schiltknecht wrote: > Hi, > > Jeff Davis wrote: > > I disagree about high-availability. In fact, I would say that sync > > replication is trading availability and performance for synchronization > > (which is a valid tradeoff, but costly). > > In a way, r

Re: [HACKERS] Replication

[EMAIL PROTECTED] (Jeff Davis) writes: > On Wed, 2006-08-23 at 13:36 +0200, Markus Schiltknecht wrote: >> Hannu Krosing wrote: >> > But if you have very few writes, then there seems no reason to do sync >> > anyway. >> >> I think there is one: high-availability. A standby-server which can >> cont

Re: [HACKERS] Replication

Hi, Jeff Davis wrote: I disagree about high-availability. In fact, I would say that sync replication is trading availability and performance for synchronization (which is a valid tradeoff, but costly). In a way, replication is for databases systems what RAID1 is for hard drives. Having multip

Re: [HACKERS] Replication

On Wed, 2006-08-23 at 13:36 +0200, Markus Schiltknecht wrote: > Hannu Krosing wrote: > > But if you have very few writes, then there seems no reason to do sync > > anyway. > > I think there is one: high-availability. A standby-server which can > continue if your primary fails. Of course sync is o

Re: [HACKERS] Replication

Hi, Hannu Krosing wrote: but it still needs to do at least one network roundtrip + any needed testing on all nodes + WAL sync on all nodes before it can COMMIT, no? No. It only needs the 'roundtrip' in the sense that a transaction sends out its writeset and has to wait for the GCS to have it

Re: [HACKERS] Replication

Ühel kenal päeval, K, 2006-08-23 kell 13:36, kirjutas Markus Schiltknecht: > Hannu Krosing wrote: > > But if you have very few writes, then there seems no reason to do sync > > anyway. > > I think there is one: high-availability. A standby-server which can > continue if your primary fails. Of cou

Re: [HACKERS] Replication

On Wed, 23 Aug 2006 12:42:11 +0300 Hannu Krosing <[EMAIL PROTECTED]> wrote: > > OK, that solves your problem. How about my problem where replication > > has to happen on servers in three countries on two continents and > > thousands of updates a second have to happen in less that 10ms? > > For t

Re: [HACKERS] Replication

Hannu Krosing wrote: But if you have very few writes, then there seems no reason to do sync anyway. I think there is one: high-availability. A standby-server which can continue if your primary fails. Of course sync is only needed if you absolutely cannot effort loosing any committed transacti

Re: [HACKERS] Replication

Ühel kenal päeval, K, 2006-08-23 kell 13:09, kirjutas Markus Schiltknecht: > Hannu Krosing wrote: > > But any sync _replication_ system will have severe impact on > > performance. My guess is that for a full sync replication, going from 1 > > server to 2 will actually lower performance andsome smal

Re: [HACKERS] Replication

Hannu Krosing wrote: But any sync _replication_ system will have severe impact on performance. My guess is that for a full sync replication, going from 1 server to 2 will actually lower performance andsome small gains would be possible only starting from 3rd server. Only testing will show concr

Re: [HACKERS] Replication

Ühel kenal päeval, E, 2006-08-21 kell 15:00, kirjutas D'Arcy J.M. Cain: > On Mon, 21 Aug 2006 14:46:05 -0400 > "Gregory Maxwell" <[EMAIL PROTECTED]> wrote: > > On 8/21/06, Alvaro Herrera <[EMAIL PROTECTED]> wrote: > > > But the confirmation that needs to come is that the WAL changes have > > > been

Re: [HACKERS] Replication

Ühel kenal päeval, E, 2006-08-21 kell 21:46, kirjutas Fujii Masao: > Stefan Kaltenbrunner wrote: > > It is however async replication so you can loose data commited on the > > master but not yet replicated to the slaves in case you loose the master > > completely. > > Yes, here is an insufficient

Re: [HACKERS] Replication

On Mon, 21 Aug 2006 15:14:10 -0400 AgentM <[EMAIL PROTECTED]> wrote: > > My experience is that any replication needs to be based on your > > business > > rules which will vary widely. > > Sure- and more specifically, replication rules may differ on every > table according to those rules. The c

Re: [HACKERS] Replication

AgentM wrote: > > On Aug 21, 2006, at 15:00 , D'Arcy J.M. Cain wrote: > > >On Mon, 21 Aug 2006 14:46:05 -0400 > >"Gregory Maxwell" <[EMAIL PROTECTED]> wrote: > >>On 8/21/06, Alvaro Herrera <[EMAIL PROTECTED]> wrote: > >>>But the confirmation that needs to come is that the WAL changes have > >>>be

Re: [HACKERS] Replication

Jeff Davis wrote: Synchronous replication (to me) means that the data has been written to permanent storage on all masters and all slaves before any master or slave reports a successful COMMIT. Are you suggesting that you ship the WAL over the network, wait for it to be written to the slave, and

Re: [HACKERS] Replication

On Aug 21, 2006, at 15:00 , D'Arcy J.M. Cain wrote: On Mon, 21 Aug 2006 14:46:05 -0400 "Gregory Maxwell" <[EMAIL PROTECTED]> wrote: On 8/21/06, Alvaro Herrera <[EMAIL PROTECTED]> wrote: But the confirmation that needs to come is that the WAL changes have been applied (fsync'ed), so the perfor

Re: [HACKERS] Replication

Gregory Maxwell wrote: infiniband is cheap.. Can I get one? I'd love to run some tests with Postgres-R ;-) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq

Re: [HACKERS] Replication

Alvaro Herrera wrote: But the confirmation that needs to come is that the WAL changes have been applied (fsync'ed), so the performance will be terrible. So bad, that I don't think anyone will want to use such a replication system ... Yeah, that's the big problem of sync, multi-master replicati

Re: [HACKERS] Replication

On Mon, 21 Aug 2006 14:46:05 -0400 "Gregory Maxwell" <[EMAIL PROTECTED]> wrote: > On 8/21/06, Alvaro Herrera <[EMAIL PROTECTED]> wrote: > > But the confirmation that needs to come is that the WAL changes have > > been applied (fsync'ed), so the performance will be terrible. So bad, > > that I don'

Re: [HACKERS] Replication

On Mon, 2006-08-21 at 19:42 +0200, Markus Schiltknecht wrote: > Jeff Davis wrote: > > How does WAL shipping help synchronous replication? > > The WAL is written _before_ commit, logging all the changes the > transaction wants to write to the disk. This makes it look very similar > to what is n

Re: [HACKERS] Replication

On 8/21/06, Alvaro Herrera <[EMAIL PROTECTED]> wrote: But the confirmation that needs to come is that the WAL changes have been applied (fsync'ed), so the performance will be terrible. So bad, that I don't think anyone will want to use such a replication system ... Okay. I give up... Why is wa

Re: [HACKERS] Replication

Markus Schiltknecht wrote: > Jeff Davis wrote: > > How does WAL shipping help synchronous replication? > > The WAL is written _before_ commit, logging all the changes the > transaction wants to write to the disk. This makes it look very similar > to what is needed for synchronous replication. >

Re: [HACKERS] Replication

Jeff Davis wrote: > How does WAL shipping help synchronous replication? The WAL is written _before_ commit, logging all the changes the transaction wants to write to the disk. This makes it look very similar to what is needed for synchronous replication. Instead of waiting for confirmation f

Re: [HACKERS] Replication

On Mon, 2006-08-21 at 11:33 -0400, AgentM wrote: > I would imagine that multi-master synchronous replication would be > fairly trivial to implement with 2PC and wal-shipping available, no? > How does WAL shipping help synchronous replication? Regards, Jeff Davis -

Re: [HACKERS] Replication

Fujii Masao wrote: > Stefan Kaltenbrunner wrote: >> It is however async replication so you can loose data commited on the >> master but not yet replicated to the slaves in case you loose the master >> completely. > > Yes, here is an insufficient point of Slony-I, i think. > Most systems will not

Re: [HACKERS] Replication

Hi, AgentM wrote: I would imagine that multi-master synchronous replication would be fairly trivial to implement with 2PC and wal-shipping available, no? Yes, that could be done. And AFAIK eigter pgpool or PgCluster (1) try to do sync, multi-master replication that way. The problem is that

Re: [HACKERS] Replication

It is very, very common to have asynchronous replication. I would say the need for synchronous is far more limited (although greater desired). I would imagine that multi-master synchronous replication would be fairly trivial to implement with 2PC and wal-shipping available, no? Trivial? I w

Re: [HACKERS] Replication

On Aug 21, 2006, at 10:30 , Joshua D. Drake wrote: Fujii Masao wrote: Stefan Kaltenbrunner wrote: It is however async replication so you can loose data commited on the master but not yet replicated to the slaves in case you loose the master completely. Yes, here is an insufficient point

Re: [HACKERS] Replication

Fujii Masao wrote: Stefan Kaltenbrunner wrote: It is however async replication so you can loose data commited on the master but not yet replicated to the slaves in case you loose the master completely. Yes, here is an insufficient point of Slony-I, i think. Most systems will not permit the co

Re: [HACKERS] Replication

Stefan Kaltenbrunner wrote: It is however async replication so you can loose data commited on the master but not yet replicated to the slaves in case you loose the master completely. Yes, here is an insufficient point of Slony-I, i think. Most systems will not permit the committed data to be l

Re: [HACKERS] Replication

Fujii Masao wrote: > Joshua D. Drake wrote: >>> Modern systems *must* scale beyond a single computer, and the >>> PostgreSQL support shipped in modern Linux distros is completely >>> incapable of this. >> >> Slony-I is quite capable as a production class FOSS replication system >> and is in use wid

Re: [HACKERS] Replication

Joshua D. Drake wrote: Modern systems *must* scale beyond a single computer, and the PostgreSQL support shipped in modern Linux distros is completely incapable of this. Slony-I is quite capable as a production class FOSS replication system and is in use widely. Slony-I is not enough because

Re: [HACKERS] Replication

In contrast, the PostgreSQL team has chosen to provide hooks for replication and failover. This has led to a situation where there are multiple projects supporting replications/failover, none of which are production-ready nor shipped in a modern Linux distro. And no, we don't really provide

[HACKERS] Replication

One person who commented on the The business of Postbrsql made this comment: Posted Aug 3, 2006 8:45 UTC (Thu) by subscriber *jgarzik* [Link ]Cluster immaturity. MySQL has been shipping a workable single-master replication+failover for quite a while now in most

Re: [HACKERS] Replication Documentation

> > "There are a number of different approaches to solving the problem of > > replication, each with strengths and weaknesses. As a result, there > > are a number of different replication solutions available for > > PostgreSQL. To find out more, please refer to the website." > > Well, that's what I

Re: [HACKERS] Replication Documentation

Andrew Hammond wrote: > How about "what works with a given release at the time of the > release"? We just threw that idea out in the context of the procedural language discussion because we do not have the resources to check what works. > Arguably, neither are most of the procedural languages in

Re: [HACKERS] Replication Documentation

Markus Schiltknecht wrote: > Hi, > > Andrew Hammond wrote: > > I can see value in documenting what replication systems are known to > > work (for some definition of work) with a given release in the > > documentation for that release. Five years down the road when I'm > > trying to implement repl

Re: [HACKERS] Replication Documentation

Hi, Andrew Hammond wrote: > I can see value in documenting what replication systems are known to work (for some definition of work) with a given release in the documentation for that release. Five years down the road when I'm trying to implement replication for a client who's somehow locked int

Re: [HACKERS] Replication Documentation

Peter Eisentraut wrote: > Alvaro Herrera wrote: > > > >I don't think this sort of material belongs directly into the > > > > PostgreSQL documentation. > > > > Why not? > > PostgreSQL documentation (or any product documentation) should be > factual: describe what the software does and give advice on

Re: [HACKERS] Replication on the backend

Hello, On Fri, 2005-12-09 at 08:47 -0500, Christopher Browne wrote: > We *know* (particularly those of us that have had involvement in > actually implementing replication systems used in production > environments) that "user space" implementations of replication can > function satisfactorily. We'

Re: [HACKERS] Replication on the backend

> Are you sure that no way to implement a generic aproach on the > backend? What does specification say? What specification are you talking about? > Does Oracle 10g have a core implementation of replication (cluster)? Since replication is sold as a separate product from Oracle 10g, obviously not

Re: [HACKERS] Replication on the backend

On 12/8/2005 1:28 PM, Gustavo Tonini wrote: Are you sure that no way to implement a generic aproach on the backend? What You mean "generic" as in a replication system that can do asynchronous master-slave, asynchronous multimaster with conflict resolution based on timestamps, system priority

Re: [HACKERS] Replication on the backend

What is the point of these questions? If you have a concrete, practical proposal to make, please do so. Otherwise, you have already got the answer from the people who are actually working on replication and understand it far beyond abstract considerations. If you think there is a good reason

Re: [HACKERS] Replication on the backend

Are you sure that no way to implement a generic aproach on the backend? What does specification say? Does Oracle 10g have a core implementation of replication (cluster)? Gustavo. 2005/12/7, Andrew Sullivan <[EMAIL PROTECTED]>: On Tue, Dec 06, 2005 at 12:35:43AM -0500, Jan Wieck wrote:> We do not p

Re: [HACKERS] Replication on the backend

On Tue, Dec 06, 2005 at 12:35:43AM -0500, Jan Wieck wrote: > We do not plan to implement replication inside the backend. Replication > needs are so diverse that pluggable replication support makes a lot more > sense. To me it even makes more sense than keeping transaction support > outside of th

Re: [HACKERS] Replication on the backend

Andrew, > And if postgres could actually use an infiniband fabric for > clustering a single database instance across Opteron servers, that > would be very impressive... That's what we do with Bizgres MPP. We've implemented an interconnect to do the data shuffling underneath the optimizer/exe

Re: [HACKERS] Replication on the backend

On Dec 6, 2005, at 11:42 PM, Markus Schiltknecht wrote: Does anybody have latency / roundtrip measurements for current hardware? I'm interested in: 1Gb Ethernet, 10 Gb Ethernet, InfiniBand, probably even p2p usb2 or firewire links? In another secret life, I k

Re: [HACKERS] Replication on the backend

On Dec 6, 2005, at 9:09 PM, Gregory Maxwell wrote: Eh, why would light limited delay be any slower than a disk on FC the same distance away? :) In any case, performance of PG on iscsi is just fine. You can't blame the network... Doing multimaster replication is hard because the locking primitiv

Re: [HACKERS] Replication on the backend

On Wed, 2005-12-07 at 01:04 -0800, J. Andrew Rogers wrote: > Opteron boards get pretty damn close to Big Iron SMP fabric > performance in a cheap package. Given how many companies have > announced plans to produce Opteron server boards with Infiniband > fabrics directly integrated into Hyper

Re: [HACKERS] Replication on the backend

On Tue, 2005-12-06 at 23:19 -0500, Jan Wieck wrote: > It's not so much the bandwidth but more the roundtrips that limit your > maximum transaction throughput. I completely agree that the latency is counting, not the bandwith. Does anybody have latency / roundtrip measurements for current hardwa

Re: [HACKERS] Replication on the backend

On 12/6/05, Jan Wieck <[EMAIL PROTECTED]> wrote: > > IMO this is not true. You can get affordable 10GBit network adapters, so > > you can have plenty of bandwith in a db server pool (if they are located in > > the same area). Even 1GBit Ethernet greatly helps here, and would make it > > possible

Re: [HACKERS] Replication on the backend

To: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Replication on the backend [EMAIL PROTECTED] (Gustavo Tonini) writes: But, wouldn't the performance be better? And wouldn't asynchronous messages be better processed? Why do you think performance would be materially affected

Re: [HACKERS] Replication on the backend

I would classify it as a clustered database system (Oracle 10g that is). Clustered meaning more than one node in the cluster. ALy. On Tue, 6 Dec 2005, Michael Meskes wrote: >> Postgres-R, pgcluster, Slony-II. Some more advanced, some less. But >> certainly nothing I would send into the

Re: [HACKERS] Replication on the backend

I don't see anything in the TODO list. I'm very interesting in work that. If is possible... Gustavo.

Re: [HACKERS] Replication on the backend

- Asynchronous master to multi-slave. We have a few of those with Mommoth-Replicator and Slony-I being the top players. Slony-I does need some cleanup and/or reimplementation after we have a general pluggable replication API in place. Is this API actually have people working on it

Re: [HACKERS] Replication on the backend

Just like MySql! On Dec 5, 2005, at 10:35 PM, Jan Wieck wrote: On 12/5/2005 8:18 PM, Gustavo Tonini wrote: replication (master/slave, multi-master, etc) implemented inside postgres...I would like to know what has been make in this area. We do not plan to implement replication inside the bac

Re: [HACKERS] Replication on the backend

> Postgres-R, pgcluster, Slony-II. Some more advanced, some less. But > certainly nothing I would send into the ring against Oracle-Grid. Assuming that you mean Oracle Real Application Cluster (the Grid is more, right?) I wonder if this technology technically still counts as replication

Re: [HACKERS] Replication on the backend

Chris Browne Sent: Tuesday, December 06, 2005 4:43 PM To: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Replication on the backend [EMAIL PROTECTED] (Gustavo Tonini) writes: > But,  wouldn't the performance be better? And wouldn't asynchronous > messages be better processed?

Re: [HACKERS] Replication on the backend

[EMAIL PROTECTED] (Gustavo Tonini) writes: > But,  wouldn't the performance be better? And wouldn't asynchronous > messages be better processed? Why do you think performance would be materially affected by this? The MAJOR performance bottleneck is normally the slow network connection between serv

Re: [HACKERS] Replication on the backend

Hello Jan, On Tue, 2005-12-06 at 10:10 -0500, Jan Wieck wrote: > We need a general API. It should be possible to define on a per-database > level which shared replication module to load on connect. The init > function of that replication module then installs all the required > callbacks at stra

Re: [HACKERS] Replication on the backend

On 12/6/2005 8:10 AM, Markus Schiltknecht wrote: On Tue, 2005-12-06 at 10:03 -0200, Gustavo Tonini wrote: But, wouldn't the performance be better? And wouldn't asynchronous messages be better processed? At least for synchronous multi-master replication, the performance bottelneck is going to

Re: [HACKERS] Replication on the backend

On Tue, 2005-12-06 at 10:03 -0200, Gustavo Tonini wrote: > But, wouldn't the performance be better? And wouldn't asynchronous > messages be better processed? At least for synchronous multi-master replication, the performance bottelneck is going to be the interconnect between the nodes - integrati

<    1   2   3   4   5   6   7   >