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 surprise path..
--
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
controlled by log_connections like normal ones? There's a comment in
the
Magnus Hagander mag...@hagander.net 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
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 surprise
On Sun, Jan 16, 2011 at 9:19 AM, Magnus Hagander mag...@hagander.net 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
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 goes
On Mon, Jan 17, 2011 at 07:44, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
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 -
On Mon, Jan 17, 2011 at 03:06, Robert Haas robertmh...@gmail.com wrote:
On Sun, Jan 16, 2011 at 9:19 AM, Magnus Hagander mag...@hagander.net wrote:
Currently, replication connections *always* logs something like:
LOG: replication connection authorized: user=mha host=[local]
There's no way to
On Thu, Jan 7, 2010 at 1:51 AM, Tom Lane t...@sss.pgh.pa.us 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
On Thu, Jan 7, 2010 at 07:19, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Jan 6, 2010 at 11:11 PM, Magnus Hagander mag...@hagander.net 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
On Thu, Jan 7, 2010 at 09:26, Fujii Masao masao.fu...@gmail.com 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
On Thu, Jan 7, 2010 at 5:44 PM, Magnus Hagander mag...@hagander.net 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
On Thu, Jan 7, 2010 at 5:46 PM, Magnus Hagander mag...@hagander.net 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
Fujii Masao wrote:
On Thu, Jan 7, 2010 at 5:44 PM, Magnus Hagander mag...@hagander.net 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?
Tom Lane wrote:
Fujii Masao masao.fu...@gmail.com 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
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
On Thu, Jan 7, 2010 at 10:21, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, Jan 7, 2010 at 5:46 PM, Magnus Hagander mag...@hagander.net wrote:
However, wouldn't it make more logical sense to replace host/hostssl
with replication/replicationssl rather than overload the database
field?
On Thu, Jan 7, 2010 at 13:34, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Fujii Masao wrote:
On Thu, Jan 7, 2010 at 5:44 PM, Magnus Hagander mag...@hagander.net wrote:
Such information are supplied in the parameter 'primary_conninfo' of
recovery.conf. For example;
Fujii Masao masao.fu...@gmail.com writes:
On Thu, Jan 7, 2010 at 5:46 PM, Magnus Hagander mag...@hagander.net 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
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 patch
Fujii Masao escribió:
On Sat, Dec 26, 2009 at 10:55 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Fri, Dec 25, 2009 at 9:56 PM, Andrew Dunstan and...@dunslane.net wrote:
I don't see the use case for it - .pgpass is for single users, not a whole
cluster. And it does support wildcards,
On Wed, Jan 6, 2010 at 15:02, Alvaro Herrera alvhe...@commandprompt.com wrote:
Fujii Masao escribió:
On Sat, Dec 26, 2009 at 10:55 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Fri, Dec 25, 2009 at 9:56 PM, Andrew Dunstan and...@dunslane.net
wrote:
I don't see the use case for it -
Fujii Masao masao.fu...@gmail.com 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
On Wed, Jan 6, 2010 at 11:11 PM, Magnus Hagander mag...@hagander.net 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
On Sat, Dec 26, 2009 at 10:55 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Fri, Dec 25, 2009 at 9:56 PM, Andrew Dunstan and...@dunslane.net 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'
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
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
On 5/29/08, Andrew Sullivan [EMAIL PROTECTED] wrote:
On Thu, May 29, 2008 at 12:05:18PM -0700, Robert Hodges wrote:
people are starting to get religion on this issue I would strongly
advocate a parallel effort to put in a change-set extraction API
that would allow construction of
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
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 irritant, so
-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 spacial
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 someone
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. (I
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
On Wed, Oct 25, 2006 at 08:42:07PM -0400, Bruce Momjian wrote:
Jim C. Nasby wrote:
Something else worth doing though is to have a paragraph explaining why
there's no built-in replication. I don't have time to write something
right now, but I can do it later tonight if no one beats me to it.
Jim C. Nasby wrote:
On Wed, Oct 25, 2006 at 08:42:07PM -0400, Bruce Momjian wrote:
Jim C. Nasby wrote:
Something else worth doing though is to have a paragraph explaining why
there's no built-in replication. I don't have time to write something
right now, but I can do it later tonight
Joshua D. Drake wrote:
Bruce Momjian wrote:
Jim C. Nasby wrote:
On Wed, Oct 25, 2006 at 08:42:07PM -0400, Bruce Momjian wrote:
Jim C. Nasby wrote:
Something else worth doing though is to have a paragraph explaining why
there's no built-in replication. I don't have time to write
Bruce Momjian wrote:
Jim C. Nasby wrote:
On Wed, Oct 25, 2006 at 08:42:07PM -0400, Bruce Momjian wrote:
Jim C. Nasby wrote:
Something else worth doing though is to have a paragraph explaining why
there's no built-in replication. I don't have time to write something
right now, but I can do it
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
The documentation comes with the open source tarball.
Yuck.
I would welcome if the docs point to an unofficial wiki (maintained
externally from authoritative PostgreSQL developers) or a website
listing them and giving a brief of each solution.
postgresql.org already does this for events
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 to be decided
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 examples.
On Thu, Oct 26, 2006 at 11:59:57AM -0400, Bruce Momjian wrote:
Jim C. Nasby wrote:
On Wed, Oct 25, 2006 at 08:42:07PM -0400, Bruce Momjian wrote:
Jim C. Nasby wrote:
Something else worth doing though is to have a paragraph explaining why
there's no built-in replication. I don't have
Jim C. Nasby wrote:
On Thu, Oct 26, 2006 at 11:59:57AM -0400, Bruce Momjian wrote:
Jim C. Nasby wrote:
On Wed, Oct 25, 2006 at 08:42:07PM -0400, Bruce Momjian wrote:
Jim C. Nasby wrote:
Something else worth doing though is to have a paragraph explaining
why
there's no
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 linked in
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
Krosing
Cc: PostgreSQL-documentation; PostgreSQL-development
Subject: Re: [HACKERS] Replication documentation addition
OK, I have updated the URL. Please let me know how you like it.
There's a typo on line 8, first paragraph:
perhaps with only one server allowing write
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
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
Bruce Momjian wrote:
OK, does that mean we mention EnterpriseDB in the section about Oracle
functions? Why not mention MS SQL if they have a better solution? I
just don't see where that line can clearly be drawn on what to include.
Do we mention Netiza, which is loosely based on PostgreSQL?
On Wed, Oct 25, 2006 at 08:22:25PM +0930, Shane Ambler wrote:
Bruce Momjian wrote:
OK, does that mean we mention EnterpriseDB in the section about Oracle
functions? Why not mention MS SQL if they have a better solution? I
just don't see where that line can clearly be drawn on what to
On Wed, Oct 25, 2006 at 11:38:11AM +0200, Markus Schiltknecht wrote:
I can't really get excited about the exclusion of the term
'replication', because it's what most people are looking for. It's a
well known term. Sorry if it sounded that way, but I've not meant to
avoid that term.
snip
I am not inclined to add commercial offerings. If people wanted
commercial database offerings, they can get them from companies that
advertize. People are coming to PostgreSQL for open source solutions,
and I think mentioning commercial ones doesn't make sense.
If we are to add them, I
A big part of the value of Postgresql is the applications and extensions
that support it. Hiding the existence of some subset of those just
because of the way they're licensed is both underselling postgresql
and doing something of a disservice to the user of the document.
OK, does that
Hi, Cesar,
Cesar Suga wrote:
If people (who read the documentation) professionally work with
PostgreSQL, they may already have been briefed by those commercial
offerings in some way.
I think only the source and its tightly coupled (read: can compile along
with, free as PostgreSQL)
Cesar Suga wrote:
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
I would think that companies that sell closed-source solutions for
PostgreSQL would be modest enough not to push their own agenda for the
documentation. I think they should just sit back and hope others
suggest it.
[ Josh Berkus recently left Green Plum for Sun. ]
,
-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 documentation addition
Bruce Momjian wrote:
I would think that companies that sell closed-source solutions for
PostgreSQL would be modest enough not to push their own agenda for the
documentation. I think they should just sit back and hope others
suggest it.
[ Josh Berkus recently left Green Plum for Sun. ]
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.
they change their business model, if and if.
That is no different than the open source offerings. We have
had several open source offerings that have died over the
years. Replicator, for example has always been Replicator and
has been around longer than any of the current replication
Magnus Hagander [EMAIL PROTECTED] writes:
I think this is a good reason not to list *any* of the products by name
in the documentation, but instead refer to a page on say techdocs that
can be more easily updated.
I agree with that. If we have statements about other projects in our
docs, we
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
I think this is a good reason not to list *any* of the products by name
in the documentation, but instead refer to a page on say techdocs that
can be more easily updated.
I agree with that. If we have statements about other projects
Markus Schiltknecht wrote:
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
Jim C. Nasby wrote:
On Wed, Oct 25, 2006 at 11:38:11AM +0200, Markus Schiltknecht wrote:
I can't really get excited about the exclusion of the term
'replication', because it's what most people are looking for. It's a
well known term. Sorry if it sounded that way, but I've not meant to
Hi,
Jim C. Nasby wrote:
Those to statements are at odds with each other, at least based on
everyone I've ever talked to in a commercial setting. People will use
terms like 'replication', 'HA' or 'clustering' fairly interchangably.
Usually what these folks want is some kind of high-availability
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
I think this is a good reason not to list *any* of the products by name
in the documentation, but instead refer to a page on say techdocs that
can be more easily updated.
I agree with that. If we have statements about other
Bruce Momjian wrote:
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
I think this is a good reason not to list *any* of the products by name
in the documentation, but instead refer to a page on say techdocs that
can be more easily updated.
I agree with that. If we have statements
Joshua D. Drake wrote:
Bruce Momjian wrote:
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
I think this is a good reason not to list *any* of the products by name
in the documentation, but instead refer to a page on say techdocs that
can be more easily updated.
I agree with
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:
On Wed, Oct 25, 2006 at 11:38:11AM +0200, Markus Schiltknecht wrote:
Can we name the chapter Fail-over, Load-Balancing and Replication
Options? That would fit everything and contain the necessary buzz words.
...
IMHO, it does not make sense to speak of a synchronous replication for a
David Fetter wrote:
On Wed, Oct 25, 2006 at 11:38:11AM +0200, Markus Schiltknecht wrote:
Can we name the chapter Fail-over, Load-Balancing and Replication
Options? That would fit everything and contain the necessary buzz words.
...
IMHO, it does not make sense to speak of a
Totally agree. The docs will tend to outlive whatever projects or
websites they mention. Best to not bake that into stone.
-Casey
On Oct 25, 2006, at 3:36 AM, Magnus Hagander wrote:
I don't think the PostgreSQL documentation should be
mentioning commercial solutions.
I think maybe the
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 whole
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 to add for
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
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 other spots
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 for
On 10/25/06, Bruce Momjian [EMAIL PROTECTED] wrote:
Joshua D. Drake wrote:
Bruce Momjian wrote:
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
I think this is a good reason not to list *any* of the products by name
in the documentation, but instead refer to a page on say
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
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 they? I've
Dawid Kuroczko wrote:
Bruce, I've read Your documentation and I was left a bit with a feeling
that it's a bit too generic. It's almost as if it could be about just about
any major database, not PostgreSQL specific. I feel that, when I'm
reading PostgreSQL docs I would like to know how to set
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
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 PROTECTED]
On Wed, Oct 25, 2006 at 04:42:17PM -0400, Bruce Momjian wrote:
Dawid Kuroczko wrote:
Bruce, I've read Your documentation and I was left a bit with a feeling
that it's a bit too generic. It's almost as if it could be about just about
any major database, not PostgreSQL specific. I feel
Jim C. Nasby wrote:
Something else worth doing though is to have a paragraph explaining why
there's no built-in replication. I don't have time to write something
right now, but I can do it later tonight if no one beats me to it.
I thought that was implied in the early paragraph about why there
Joshua D. Drake wrote:
Cesar Suga wrote:
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
Ü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
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.
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
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
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.
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 and
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 some
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
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 replication
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 go in).
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 pooling
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. This
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
doesn't go
401 - 500 of 625 matches
Mail list logo
