On Sat, 2008-01-19 at 23:46 +, Gordan Bobic wrote:
David Fetter wrote:
In that case, use one of the existing solutions. They're all way
easier than re-inventing the wheel.
Existing solutions can't handle multiple masters. MySQL can do it at
least in a ring arrangement.
What
On Jan 19, 2008 6:46 PM, Gordan Bobic [EMAIL PROTECTED] wrote:
Existing solutions can't handle multiple masters. MySQL can do it at
least in a ring arrangement.
mysql multi-master replication looks a lot better on paper than it
really is...one of the reasons mysql is able to seemingly provide
On Fri, Jan 18, 2008 at 09:27:08PM +, Gordan Bobic wrote:
Andrew Sullivan wrote:
On Fri, Jan 18, 2008 at 04:09:45PM +, [EMAIL PROTECTED] wrote:
That's just it - I don't think any user-land libraries would
actually be required. One of supposed big advantages of MySQL is
it's
David Fetter wrote:
That's just it - I don't think any user-land libraries would
actually be required. One of supposed big advantages of MySQL is
it's straightforward replication support. It's quite painful to
see PostgreSQL suffer purely for the sake of lack of marketting in
this department.
Gregory Youngblood wrote:
On Sat, 2008-01-19 at 23:46 +, Gordan Bobic wrote:
David Fetter wrote:
In that case, use one of the existing solutions. They're all way
easier than re-inventing the wheel.
Existing solutions can't handle multiple masters. MySQL can do it at
least in a ring
On Jan 19, 2008 5:46 PM, Gordan Bobic [EMAIL PROTECTED] wrote:
David Fetter wrote:
That's just it - I don't think any user-land libraries would
actually be required. One of supposed big advantages of MySQL is
it's straightforward replication support. It's quite painful to
see PostgreSQL
On Jan 19, 2008 6:14 PM, Gordan Bobic [EMAIL PROTECTED] wrote:
Gregory Youngblood wrote:
On Sat, 2008-01-19 at 23:46 +, Gordan Bobic wrote:
David Fetter wrote:
In that case, use one of the existing solutions. They're all way
easier than re-inventing the wheel.
Existing
Scott Marlowe wrote:
On Jan 19, 2008 6:14 PM, Gordan Bobic [EMAIL PROTECTED] wrote:
Gregory Youngblood wrote:
On Sat, 2008-01-19 at 23:46 +, Gordan Bobic wrote:
David Fetter wrote:
In that case, use one of the existing solutions. They're all way
easier than re-inventing the wheel.
On Sun, 20 Jan 2008 00:34:11 + Gordan Bobic wrote:
Scott Marlowe wrote:
On Jan 19, 2008 6:14 PM, Gordan Bobic [EMAIL PROTECTED] wrote:
Oh, and there's this too:
Cybertec sync-multi-master
http://www.postgresql.org/about/news.752
http://www.postgresql.org/about/news.752
The
Hi,
Is there any reason why PostgreSQL replication solutions are all add-on
3rd party ones? Is there any reason why replication couldn't be
implemented using triggers and a handful of stored procedures? This is
what I have in mind:
Have a plperl function that creates connections to all
[EMAIL PROTECTED] wrote:
On Fri, 18 Jan 2008, Erik Jones wrote:
This is what I have in mind:
Have a plperl function that creates connections to all servers in the
cluster (replication partners), and issues the supplied write query
to them, possibly with a tag of some sort to indicated it
This is what I have in mind:
Have a plperl function that creates connections to all servers in the
cluster (replication partners), and issues the supplied write query to
them, possibly with a tag of some sort to indicated it is a replicated
query (to prevent circular replication).
Have a
Andreas 'ads' Scherbaum wrote:
Have a plperl function that creates connections to all servers in the
cluster (replication partners), and issues the supplied write query to
them, possibly with a tag of some sort to indicated it is a replicated
query (to prevent circular replication).
Have a
Hello,
On Fri, 18 Jan 2008 17:37:07 + (GMT) [EMAIL PROTECTED] wrote:
This is what I have in mind:
Have a plperl function that creates connections to all servers in the
cluster (replication partners), and issues the supplied write query to
them, possibly with a tag of some sort
Andrew Sullivan wrote:
On Fri, Jan 18, 2008 at 04:09:45PM +, [EMAIL PROTECTED] wrote:
That's just it - I don't think any user-land libraries would actually be
required. One of supposed big advantages of MySQL is it's straightforward
replication support. It's quite painful to see PostgreSQL
On Fri, 18 Jan 2008, Erik Jones wrote:
Is there any reason why PostgreSQL replication solutions are all add-on 3rd
party ones?
Because no one solution would be appropriate for everyone. The core team and
contributors feel that their time is better spent on the database itself
rather than
On Jan 18, 2008, at 9:21 AM, [EMAIL PROTECTED] wrote:
Hi,
Is there any reason why PostgreSQL replication solutions are all
add-on 3rd party ones?
Because no one solution would be appropriate for everyone. The core
team and contributors feel that their time is better spent on the
On Jan 18, 2008, at 11:37 AM, [EMAIL PROTECTED] wrote:
That's one thing. The other problem that most trigger based
replication systems have problems with is propogating schema
changes - because (I think) you can attach triggers to schema
changes.
I presume you mean that you cannot
On Fri, Jan 18, 2008 at 04:09:45PM +, [EMAIL PROTECTED] wrote:
That's just it - I don't think any user-land libraries would actually be
required. One of supposed big advantages of MySQL is it's straightforward
replication support. It's quite painful to see PostgreSQL suffer purely
for
19 matches
Mail list logo
