Re: why vacuum - Mailing list pgsql-sql

From Andrew Sullivan
Subject Re: why vacuum
Date
Msg-id 20051027102120.GA26612@phlogiston.dyndns.org
Whole thread Raw
In response to Re: why vacuum  (Mario Splivalo <mario.splivalo@mobart.hr>)
Responses Re: why vacuum
List pgsql-sql
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


pgsql-sql by date:

Previous
From: Richard Huxton
Date:
Subject: Re: Complex Query - Data from 3 tables simultaneously
Next
From:
Date:
Subject: Re: Complex Query - Data from 3 tables simultaneously