In response to Csaba Nagy <nagy@ecircle-ag.com>:
> > [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
