In response to Csaba Nagy <[EMAIL PROTECTED]>: > > [snip] Take the example of a query "UPDATE tablename SET x = x + 1". > > When this query is erroneously issued twice, data corruption will occur. > > Huh ? I thought slony is replicating data, not queries... what on the > master is "UPDATE tablename SET x = x + 1" will translate to "UPDATE > tablename SET x = new_value" on the slave, where new_value equals that x > + 1. That's why slony is working well even if you do "UPDATE tablename > SET x = now()".
True. My mistake. I still wouldn't trust Slony with fsync off. Another scenario would be the Slony trigger writes a change to the Slony DB, the db crashes before it gets committed to disk. When the DB is started, no errors prevent startup, but that transaction is lost. I mean, you have to weight all these possibilities against your tolerance for data loss. If you're a bank, none of this is acceptable. If you're MySpace, who f*cking cares if you lose data (I saw an article where the CIO of MySpace admitted that was their policy -- must be nice to have a job where nobody cares if you do it wrong!) -- Bill Moran http://www.potentialtech.com ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
