Andy Dale wrote:
> I am currently researching the capabilities of Slony-l, and have so
> far managed to set up a simple example and it works (can be found here
> http://www.pgadmin.org/docs/1.4/slony/slonyadmin.html#firstdb
> <http://www.pgadmin.org/docs/1.4/slony/slonyadmin.html#firstdb> ), but
> unfortunately not in real time
You need to be quite a bit more exact about what you mean by "real time."

Based on the usual definitions of "real time," you can't reasonably
expect "real time" results from a relational database at all.

RT involves having hard guarantees as to the maximum amounts of time
that can be taken by operations, and RDBMSes behave in a decidedly
nondeterministic fashion, which pretty well ensure that you can't have
any such guarantees.

If you're prepared to live with "softer" forms of RT, where you can live
with rather fuzzier guarantees, Slony-I will nonetheless not be able to
provide all that much in the way of comfort.

Slony-I does asynchronous replication, which means that data is
replicated "some time later."  There are pathological kinds of system
behaviour that can cause "some time later" to become "some fairly
considerable time later."  Two are notable...

1.  If your system is very heavily loaded, and some resource, whether
I/O or network bandwidth, is lacking, then replication can persistently
fall behind, and there's nothing to be done about that.

2.  If your system sees "spikey" update behaviour, that is, you
occasionally have large transactions that update large numbers of
records, that will create something of a "clot", as all data for
transactions that COMMIT during a particular SYNC will be replicated as
one (perhaps rather large) transaction.

I'm not sure whether this will represent "reasonable restrictions," or
whether these sorts of implications mandate steering clear...