Re: pgpool2 vs sequoia

From: Markus Schiltknecht <markus(at)bluegap(dot)ch>
To: David Fetter <david(at)fetter(dot)org>
Cc: mljv(at)planwerk6(dot)de, pgsql-general(at)postgresql(dot)org
Subject: Re: pgpool2 vs sequoia
Date: 2007-08-06 12:16:04
Message-ID: 46B71104.7060207@bluegap.ch
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi,

David Fetter wrote:
> Very few people actually need synchronous replication, and those who
> do buy Oracle's RAC (and curse it) or use DB2's offering (and also
> curse it ;). For most purposes, fast asynchronous replication is good
> enough.

While this is certainly true, please keep in mind that async replication
always brings up the potential of conflicts, per definition - no matter
how fast it is.

IMO, it would often be a lot simpler and less expensive to use sync
replication and bite the bullet of a small commit delay (depending on
the interconnect) - but not having to deal with conflicts.

OTOH, of course there's no real (at least no OSS) solution to sync
replication, so this is just theory. I'm trying to change that with
Postgres-R [1].

As a second note, I might add that all of this really only applies to
writing transactions. Read-only transactions are, of course, not
affected by replication and can be balanced across multiple servers with
both types of replication. Only sync replication guarantees consistent
snapshots, though. Which is the reason for conflicts...

But again, this is just gray theory. And practically speaking, I'm
giving you the same general advice: prefer async replication, because
there are solutions, which are mature and used in production.

Regards

Markus

[1]: For more information, see: www.postgres-r.org

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Henrik Zagerholm 2007-08-06 12:21:10 Planner making wrong decisions 8.2.4. Insane cost calculations.
Previous Message Reinhard Max 2007-08-06 11:59:48 Re: Suse RPM's