Skip site navigation (1) Skip section navigation (2)

Re: PostgreSQL in the press again

From: Christopher Browne <cbbrowne(at)acm(dot)org>
To: pgsql-advocacy(at)postgresql(dot)org
Subject: Re: PostgreSQL in the press again
Date: 2004-11-10 05:02:35
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-advocacy
Martha Stewart called it a Good Thing when peter_e(at)gmx(dot)net (Peter Eisentraut) wrote:
> Thomas Hallgren wrote:
>> Master + read-only slaves:
>>   - Slony-I when all sites are trusted
>>   - dbMirror for untrusted slaves and/or table based master slave
>> assignment - Mammoth Replicator, proprietary ???
>>   - erServer ???
> That begs the question in turn why there are so many master/slave
> replication solutions.  I mean, I don't care, but this
> categorization doesn't really answer the original question.

I think there are multiple answers because of the combination of:

 a) Coding before thinking, where some of the systems have been
    "hacked together" without too much forethought;

 b) Greatly varying implementation strategies.

For instance, one of the big problems we encountered with eRServer was
in its use of memory.  The "snapshot" notion it uses tends to lead to
fairly spectacular RAM consumption.  Had it gotten more design effort,
earlier on, perhaps it could have been more modest in memory usage.
That became one of the design requirements for Slony-I...

Part of the history has been that people in a rush to get some form of
replication working looked at different "parts of the elephant," and,
seeing different things, implemented different things.

If a system can get a bit more "thoughtfulness" applied to it, it may
well become forcibly preferable to the other options.

>> Multi-master:
>>   - C-JDBC, Will be transaction safe once PostgreSQL has XA
>>   - pgPool, not transaction safe ???
> These are not multimaster solutions in the sense that you can write
> to any one of multiple hosts.  In a sense, they are really
> master/slave solutions with the program components distributed
> differently.  To write, you always have to go through one host.

The pgpool approach is somewhat ambiguous, but you're probably right.

My expectation of a "multimaster" system is that I should be able to
fire an update at any of the 'masters' and expect it to propagate to
the rest of the databases more or less automatically.  That's not what
either XA or pgpool do.
(format nil "~S(at)~S" "cbbrowne" "")
Rules of  the Evil Overlord  #158. "I will  exchange the labels  on my
folder of  top-secret plans and  my folder of family  recipes. Imagine
the  hero's  surprise when  he  decodes  the  stolen plans  and  finds
instructions for Grandma's Potato Salad."

In response to


pgsql-advocacy by date

Next:From: Anton de WetDate: 2004-11-10 09:18:20
Subject: Re: Lab System using PostgreSQL
Previous:From: Robert TreatDate: 2004-11-10 01:19:55
Subject: Re: PostgreSQL in the press again

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group