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 provid
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.
>
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
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.
Exi
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 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
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 ar
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. :-
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
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 p
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
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, 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
>
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 attac
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 pos
[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 i
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
datab
18 matches
Mail list logo
