Re: GDQ iimplementation - Mailing list pgsql-cluster-hackers

From Jan Wieck
Subject Re: GDQ iimplementation
Date
Msg-id 4BE98028.2050608@Yahoo.com
Whole thread Raw
In response to Re: GDQ iimplementation  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-cluster-hackers
On 5/11/2010 11:11 AM, Simon Riggs wrote:
> On Tue, 2010-05-11 at 10:38 -0400, Jan Wieck wrote:
>
>> Slony replication has meant both too from the beginning.
>
> You've done a brilliant job and I have huge respect for that.
>
> MHO: The world changes and new solutions emerge. Assimilation of
> technology into lower layers of the stack has been happening for years.
> The core parts of Slony should be assimilated, just as TCP/IP now exists
> as part of the OS, to the benefit of all. Various parts of Slony have
> already moved to core. Slony continues to have huge potential, though as
> part of an evolution, not in all cases fulfilling the same role it did
> at the beginning. Log shipping cannot easily exist outside of core,
> though SQL shipping can: but should it? How much more could we do?

I don't have any problem with assimilation of technology or moving
things into core if appropriate.

What I have a problem with is stuffing things into core for minor
advantages, then later discovering that we lost flexibility essential
for important features.

Right now one can use Slony 2.0 to do PostgreSQL major version upgrades
via switchover. Using pgbouncer, these can even be done transparent to
the application without the need to reconnect to the new master. I think
Londiste has or is at least working on similar features.

This is because Slony 2.0 is a separate product only relying on very
stable core functionality, like txid's and snapshots.

Are you ready to "guarantee" that the queue and transport mechanism, you
want to put into core, is THAT stable and major version independent? I
would not, but that may be just me.


Jan

--
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin

pgsql-cluster-hackers by date:

Previous
From: Jan Wieck
Date:
Subject: Re: GDQ iimplementation
Next
From: Marko Kreen
Date:
Subject: Re: GDQ iimplementation