Re: Level of replication support?

In an attempt to throw the authorities off his trail, jd(at)commandprompt(dot)com ("Joshua D. Drake") transmitted:
> Slony replicates data every (10?) transactions.

No, Slony-I replicates each and every transaction that it processes,
identifying it as a transaction independent of others.

In practice, it is usually preferable to group updates together when
_applying_ them into destination systems; how much or how little
grouping is done is configurable.

> Mammoth Replicator replicates every transaction.

Just like Slony-I ;-).

> Mammoth is older than Slony and backed by my company Command Prompt,
> Inc.

> Neither is slated to be "integrated" with PostgreSQL as they are both
> good products that serve different purposes.

An excellent reason NOT to integrate these systems tightly is that it
allows them to be used between _different_ versions of PostgreSQL,
between different platforms, and such.

One of the common "use cases" people have been finding finding for
Slony-I hasn't got to do with maintaining replicas, but rather to do
with doing quick upgrades to a new version of PostgreSQL.

Rather than doing a pg_dump, and having to sit in downtime from the
time the dump starts until when it is applied, you set up a
replication target on the newer version of PostgreSQL. If it takes 3
days to bring the target "online" and up to date, that doesn't
"matter" because it isn't downtime for the live system.

Once the target is up to date, it can take seconds to minutes to
merely switch over to the new PG database, rather than the hours
needed by less sophisticated methods. No doubt the same can be done
with Mammoth Replicator.

Tight integration with the database discourages that sort of thing.
--
(reverse (concatenate 'string "gro.mca" "@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/spreadsheets.html
Signs of a Klingon Programmer - 1. "Defensive programming? Never!
Klingon programs are always on the offense. Yes, offensive programming
is what we do best."