Re: [HACKERS] replication and pg_hba.conf

On 16.01.2011 22:55, Josh Berkus wrote: In 9.0, we specifically require using "replication" as database name to start a replication session. In 9.1 we will have the REPLICATION attribute to a role - should we change it so that "all" in database includes replication connections? It certainly goe

Re: [HACKERS] Replication logging

On Sun, Jan 16, 2011 at 9:19 AM, Magnus Hagander wrote: > Currently, replication connections *always* logs something like: > LOG:  replication connection authorized: user=mha host=[local] > > There's no way to turn that off. > > I can't find the reasoning behind this - why is this one not > contro

Re: [HACKERS] replication and pg_hba.conf

> In 9.0, we specifically require using "replication" as database name > to start a replication session. In 9.1 we will have the REPLICATION > attribute to a role - should we change it so that "all" in database > includes replication connections? It certainly goes in the "principle > of least surp

Re: [HACKERS] replication and pg_hba.conf

Magnus Hagander writes: > In 9.0, we specifically require using "replication" as database name > to start a replication session. In 9.1 we will have the REPLICATION > attribute to a role - should we change it so that "all" in database > includes replication connections? It certainly goes in the "p

Re: [HACKERS] 'replication' keyword on .pgpass (Streaming Replication)

Tom Lane wrote: > I'm getting more and more confused here. I thought we were talking > about client-side .pgpass. This seems to be talking about pg_hba.conf. Yeah, the topic was covertly changed. It seems we have consensus to not change .pgpass, and to leave pg_hba.conf as it is now in the patc

Re: [HACKERS] 'replication' keyword on .pgpass (Streaming Replication)

Fujii Masao writes: > On Thu, Jan 7, 2010 at 5:46 PM, Magnus Hagander wrote: >> However, wouldn't it make more logical sense to replace "host/hostssl" >> with "replication/replicationssl" rather than overload the database >> field? > Seems good. How about the following formats? > replication

Re: [HACKERS] 'replication' keyword on .pgpass (Streaming Replication)

On Thu, Jan 7, 2010 at 13:34, Heikki Linnakangas wrote: > Fujii Masao wrote: >> On Thu, Jan 7, 2010 at 5:44 PM, Magnus Hagander wrote: Such information are supplied in the parameter 'primary_conninfo' of recovery.conf. For example;    primary_conninfo = 'host=192.168.1.50 port

Re: [HACKERS] 'replication' keyword on .pgpass (Streaming Replication)

On Thu, Jan 7, 2010 at 10:21, Fujii Masao wrote: > On Thu, Jan 7, 2010 at 5:46 PM, Magnus Hagander wrote: >> However, wouldn't it make more logical sense to replace "host/hostssl" >> with "replication/replicationssl" rather than overload the database >> field? > > Seems good. How about the follow

Re: [HACKERS] 'replication' keyword on .pgpass (Streaming Replication)

Magnus Hagander wrote: > However, wouldn't it make more logical sense to replace "host/hostssl" > with "replication/replicationssl" rather than overload the database > field? It makes more sense to me to overload the database field. When you connect for replication, you're not connecting to any pa

Re: [HACKERS] 'replication' keyword on .pgpass (Streaming Replication)

Tom Lane wrote: > Fujii Masao writes: >> The attached patch supports new keyword 'replication' on .pgpass file. >> This keyword is used to specify the password for the standby server to >> connect to the primary server. > > This strikes me as a completely bad idea. We need get no farther than >

Re: [HACKERS] 'replication' keyword on .pgpass (Streaming Replication)

Fujii Masao wrote: > On Thu, Jan 7, 2010 at 5:44 PM, Magnus Hagander wrote: >>> Such information are supplied in the parameter 'primary_conninfo' of >>> recovery.conf. For example; >>> >>>primary_conninfo = 'host=192.168.1.50 port=5432 user=foo' >> So the password can just go there, no? > > Y

Re: [HACKERS] 'replication' keyword on .pgpass (Streaming Replication)

On Thu, Jan 7, 2010 at 5:46 PM, Magnus Hagander wrote: > However, wouldn't it make more logical sense to replace "host/hostssl" > with "replication/replicationssl" rather than overload the database > field? Seems good. How about the following formats? replication user CIDR-address auth-m

Re: [HACKERS] 'replication' keyword on .pgpass (Streaming Replication)

On Thu, Jan 7, 2010 at 5:44 PM, Magnus Hagander wrote: >> Such information are supplied in the parameter 'primary_conninfo' of >> recovery.conf. For example; >> >>    primary_conninfo = 'host=192.168.1.50 port=5432 user=foo' > > So the password can just go there, no? Yeah, the password can be sup

Re: [HACKERS] 'replication' keyword on .pgpass (Streaming Replication)

On Thu, Jan 7, 2010 at 09:26, Fujii Masao wrote: > The same problem also exists in pg_hba.conf. It's because I introduced > new keyword "replication" in pg_hba.conf to authenticate the standby > server. This restriction is not acceptable? If so, I'd need to consider > an authentication configurat

Re: [HACKERS] 'replication' keyword on .pgpass (Streaming Replication)

On Thu, Jan 7, 2010 at 07:19, Fujii Masao wrote: > On Wed, Jan 6, 2010 at 11:11 PM, Magnus Hagander wrote: >> I haven't read up on the rest of the patch, but where do we put the >> rest of the information about the replication master? Like which IP >> and port to connect to? Perhaps it could/shou

Re: [HACKERS] 'replication' keyword on .pgpass (Streaming Replication)

On Thu, Jan 7, 2010 at 1:51 AM, Tom Lane wrote: > This strikes me as a completely bad idea.  We need get no farther than > the point that it assumes nobody can have a database named "replication" Though I might misunderstand your point. My proposal would force the users who have a database named

Re: [HACKERS] 'replication' keyword on .pgpass (Streaming Replication)

On Wed, Jan 6, 2010 at 11:11 PM, Magnus Hagander wrote: > I haven't read up on the rest of the patch, but where do we put the > rest of the information about the replication master? Like which IP > and port to connect to? Perhaps it could/should go there? Such information are supplied in the para

Re: [HACKERS] 'replication' keyword on .pgpass (Streaming Replication)

Fujii Masao writes: > The attached patch supports new keyword 'replication' on .pgpass file. > This keyword is used to specify the password for the standby server to > connect to the primary server. This strikes me as a completely bad idea. We need get no farther than the point that it assumes n

Re: [HACKERS] 'replication' keyword on .pgpass (Streaming Replication)

On Wed, Jan 6, 2010 at 15:02, Alvaro Herrera wrote: > Fujii Masao escribió: >> On Sat, Dec 26, 2009 at 10:55 AM, Fujii Masao wrote: >> > On Fri, Dec 25, 2009 at 9:56 PM, Andrew Dunstan >> > wrote: >> >> I don't see the use case for it - .pgpass is for single users, not a whole >> >> cluster. An

Re: [HACKERS] 'replication' keyword on .pgpass (Streaming Replication)

Fujii Masao escribió: > On Sat, Dec 26, 2009 at 10:55 AM, Fujii Masao wrote: > > On Fri, Dec 25, 2009 at 9:56 PM, Andrew Dunstan wrote: > >> I don't see the use case for it - .pgpass is for single users, not a whole > >> cluster. And it does support wildcards, which takes care of the 'all' case.

Re: [HACKERS] replication hooks

Marko Kreen wrote: There is this tiny matter of replicating schema changes asynchronously, but I suspect nobody actually cares. Few random points about that: I'm not sure I follow you - the Sybase 'warm standby' replication of everything is really useful for business continuity. The per-tab

Re: [HACKERS] replication hooks

Hi Marko, Replication requirements vary widely of course, but DDL support is shared by such a wide range of use cases it is very difficult to see how any real solution would fail to include it. This extends to change extraction APIs, however, defined. The question of what DDL to replicate is

Re: [HACKERS] replication hooks

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 > Yeah. The main problem is that unless you do WAL based replication, > you cannot achieve transparency. So you need to pick few use cases > and tailor you solution for them, which gets uninteresting very fast > - user _will_ stumble upon spac

Re: [HACKERS] replication hooks

On 5/29/08, Andrew Sullivan <[EMAIL PROTECTED]> wrote: > On Thu, May 29, 2008 at 11:05:09PM +0300, Marko Kreen wrote: > > There is this tiny matter of replicating schema changes asynchronously, > > but I suspect nobody actually cares. > > I know that Slony's users call this their number one irrit

Re: [HACKERS] replication hooks

On Thu, May 29, 2008 at 11:05:09PM +0300, Marko Kreen wrote: > There is this tiny matter of replicating schema changes asynchronously, > but I suspect nobody actually cares. I know that Slony's users call this their number one irritant, so I have my doubts nobody cares. But maybe nobody cares

Re: [HACKERS] Replication documentation addition

On Wed, 25 Oct 2006, Bruce Momjian wrote: ...snip... > > > Data partitioning is often done within a single database on a single > > server and therefore, as a concept, has nothing whatsoever to do with > > different servers. Similarly, the second paragraph of this section is > > Uh, why would

Re: [HACKERS] Replication documentation addition

On Thu, Oct 26, 2006 at 03:06:13PM -0400, Robert Treat wrote: > > Unfortunately the techdocs system won't support a url like the one above, > rather you'll end up with something more like the following > http://www.postgresql.org/docs/techdocs.54 which is the "GUI Tools Guide" > (which is link

Re: [HACKERS] Replication documentation addition

On Thursday 26 October 2006 10:45, Andrew Sullivan wrote: > On Wed, Oct 25, 2006 at 05:46:33PM -0400, Bruce Momjian wrote: > > Josh Berkus wrote: > > > So, like www.postgresql.org/docs/techdocs/replication? That would > > > work. > > > > Yes. > > I like that idea, but I think that the URL needs t

Re: [HACKERS] Replication documentation addition

On Wed, 25 Oct 2006, Josh Berkus wrote: > > Bruce, > > > It isn't designed for that. It is designed for people to understand > > what they want, and then they can look around for solutions. I think > > most agree we don't want a list of solutions in the documentation, > > though I have a few as

Re: [HACKERS] Replication documentation addition

Hi, A typo: ("a write to any server has to be _propogated_") s/propogated/propagated Bruce Momjian wrote: Here is a new replication documentation section I want to add for 8.2: ftp://momjian.us/pub/postgresql/mypatches/replication Comments welcomed. -- Regards, Alexey Klyukin

Re: [HACKERS] Replication documentation addition

With no new additions submitted today, I have moved my text into our SGML documentation: http://momjian.us/main/writings/pgsql/sgml/failover.html Please let me know what additional changes are needed. --- bruce wro

Re: [HACKERS] Replication documentation addition

On Wed, Oct 25, 2006 at 05:46:33PM -0400, Bruce Momjian wrote: > Josh Berkus wrote: > > So, like www.postgresql.org/docs/techdocs/replication? That would work. > > Yes. I like that idea, but I think that the URL needs to be decided upon, needs to be stable, and needs to be put into the docs. (

Re: [HACKERS] Replication documentation addition

Josh Berkus wrote: > Bruce, > > > Most people didn't want a list because there is no way to keep it > > current in the docs, and a secondary web site was suggested for the > > list. > > So, like www.postgresql.org/docs/techdocs/replication? That would work. Yes. -- Bruce Momjian [EMAIL P

Re: [HACKERS] Replication documentation addition

Bruce, > Most people didn't want a list because there is no way to keep it > current in the docs, and a secondary web site was suggested for the > list. So, like www.postgresql.org/docs/techdocs/replication? That would work. -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco -

Re: [HACKERS] Replication documentation addition

Josh Berkus wrote: > Bruce, > > > It isn't designed for that. It is designed for people to understand > > what they want, and then they can look around for solutions. I think > > most agree we don't want a list of solutions in the documentation, > > though I have a few as examples. > > Do the

Re: [HACKERS] Replication documentation addition

Bruce, > It isn't designed for that. It is designed for people to understand > what they want, and then they can look around for solutions. I think > most agree we don't want a list of solutions in the documentation, > though I have a few as examples. Do they? I've seen no discussion of the

Re: [HACKERS] Replication documentation addition

Josh Berkus wrote: > Bruce, > > > > > ftp://momjian.us/pub/postgresql/mypatches/replication > > I'm still not seeing anything in this patch that tells users where they can > get replication solutions for PostgreSQL, either OSS or commercial. It isn't designed for that. It is designed f

Re: [HACKERS] Replication documentation addition

Richard Troy wrote: > > > Here is a new replication documentation section I want to add for 8.2: > > > > ftp://momjian.us/pub/postgresql/mypatches/replication > > > > ...Read the document, as promissed... > > First paragraph, "(fail over)" is inconsistent with title, "failover", as > are oth

Re: [HACKERS] Replication documentation addition

Bruce, > > > ftp://momjian.us/pub/postgresql/mypatches/replication I'm still not seeing anything in this patch that tells users where they can get replication solutions for PostgreSQL, either OSS or commercial. -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco --

Re: [HACKERS] Replication documentation addition

Alexey Klyukin wrote: > Hi, > > A typo: > ("a write to any server has to be _propogated_") > s/propogated/propagated Thanks, fixed. --- > > Bruce Momjian wrote: > > Here is a new replication documentation section I want t

Re: [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 > ...Read the document, as promissed... First paragraph, "(fail over)" is inconsistent with title, "failover", as are other spots throughout the document. The wh

Re: [HACKERS] Replication documentation addition

Hi Hannu, everyone, I apologize for not having read the document in question - will do shortly. My comments are brought about by the dialogue I read on list this morning... > > Here is a new replication documentation section I want to add for 8.2: > > > > ftp://momjian.us/pub/postgresql/mypa

Re: [HACKERS] Replication documentation addition

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

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: [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: [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: [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: [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: [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 > -

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

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

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

<    1   2   3   4   5   6   >