AgentM wrote: > > On Aug 21, 2006, at 15:00 , D'Arcy J.M. Cain wrote: > > >On Mon, 21 Aug 2006 14:46:05 -0400 > >"Gregory Maxwell" <[EMAIL PROTECTED]> wrote: > >>On 8/21/06, Alvaro Herrera <[EMAIL PROTECTED]> wrote: > >>>But the confirmation that needs to come is that the WAL changes have > >>>been applied (fsync'ed), so the performance will be terrible. So > >>>bad, > >>>that I don't think anyone will want to use such a replication > >>>system ... > >> > >>Okay. I give up... Why is waiting for fsync on a fast local network > >>which takes 15us to send a message (infiniband is cheap..) an > >>unimaginable delay when we tolerate a local 8ms fsync delay on > >>systems > >>without writeback cache? > > > >OK, that solves your problem. How about my problem where replication > >has to happen on servers in three countries on two continents and > >thousands of updates a second have to happen in less that 10ms? > >This is > >the critical issue with replication - one size does not fit all. > >Syncronous replication, in particular, fits almost no one. > > > >My experience is that any replication needs to be based on your > >business > >rules which will vary widely. > > Sure- and more specifically, replication rules may differ on every > table according to those rules. The current solutions are on/off for > a list of tables. I wonder if the various pgsql replication engines > have any problems co-existing...
Althought I have never tried, I am sure Mammoth Replicator could coexist relatively sanely with Slony-I. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
