Date: Thu, 27 Oct 2005 06:21:20 -0400
From: Andrew Sullivan <ajs@crankycanuck.ca>
To: pgsql-sql@postgresql.org
Subject: Re: why vacuum
Message-ID: <20051027102120.GA26612@phlogiston.dyndns.org>
References: <200510261015.17623.lawgon@thenilgiris.com>
	<1130339980.2872.12.camel@state.g2switchworks.com>
	<1130401361.31435.15.camel@ekim>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1130401361.31435.15.camel@ekim>
User-Agent: Mutt/1.5.9i

On Thu, Oct 27, 2005 at 10:22:41AM +0200, Mario Splivalo wrote:
> offers no replication at all, you need to use slony (wich is also a poor
> replacement for a wannabe replication), or some other commercial
> products. What about 2PC? What about linking the databases from

Slony is in fact a community-supported system; so I don't know why
you think that amounts to "no replication at all".  And since this is
a community-supported system, it'd be nice if you said why it's a
"poor replacement for wannabe replication".  What's wrong with it?

> Btw, I 'ported' the merge replication from MSSQL to postgres. It
> basicaly adds triggers to every table that is 'published' for
> replication. There is a separate table to store and calculate the change
> differences from several servers (so you could do update on any of the
> servers and change will be propagated to the others). I'm missing 2PC
> badly here, I wrote some stupid python 'thingie' wich should act as 2PC
> serializer, but that's slow as hell. And triggers slow down postgres
> quite a bit.

This is interesting.  Care to package it up for others, or write a
proof-of-concept outline for the lists or General Bits or something
like that?  This is a different sort of replication people are asking
for.  Note that you get 2PC in the next Postgres release.

A


-- 
Andrew Sullivan  | ajs@crankycanuck.ca
When my information changes, I alter my conclusions.  What do you do sir?
		--attr. John Maynard Keynes