Where are we on this? Is it something that can be added to dbmirror as a patch?
--------------------------------------------------------------------------- merino silva wrote: > Hi all, > > The method I've used to convert DBMirror to a > peer-to-peer replicator was two DBMirror instances > with one considered slave of other as the master. > > Here, I've stopped the loop back by dropping the > trigger when INSERT, DELETE, UPDATE through the > DBMirror and then creating the trigger again. > > The system was tested on the > ManddrakeLinux 9.2 > Posgresql 7.3.4 > and Perl v5.8.1 > > A 'LOCK TABLE <table name> IN EXCLUSIVE MODE' > was used before dropping the trigger to prevent > updating the client database, because updates for that > database wont trigger to the remaining one while the > trigger is dropped. > > The modified DBMirror.pl is attached with this. > > Is this an acceptable solution for peer-to-peer > replication? > What can be go wrong with this approach? > > Please reply me with your suggestions. > > regards, > merino silva. > > __________________________________ > Do you Yahoo!? > Get better spam protection with Yahoo! Mail. > http://antispam.yahoo.com/tools Content-Description: DBMirror.pl [ Attachment, skipping... ] > _______________________________________________ > Pgreplication-general mailing list > [EMAIL PROTECTED] > http://gborg.postgresql.org/mailman/listinfo/pgreplication-general -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match