On Fri, Jan 20, 2006 at 07:20:00PM -0500, Jan Wieck wrote: > On 1/20/2006 6:26 PM, Jim C. Nasby wrote: > > On Fri, Jan 20, 2006 at 04:47:01PM -0500, Andrew Sullivan wrote: > >> On Fri, Jan 20, 2006 at 04:21:15PM -0500, Christopher Browne wrote: > >> > Maximizing availability, which is what HA is forcibly and unambiguously > >> > about, may not be exactly the same thing as providing guarantees that > >> > committed transactions can never be lost. > >> > >> Right. And even banks are forced to make some compromises here. For > >> instance, nobody can do 2PC or any synchronous transaction > >> replication across WANs. So a perfect, up to the millisecond version > >> of the bank can't be online somewhere else. In a system I'm familiar > >> with, the transaction log is 2PCd somewhere else at transaction time, > >> but not live data. If the remote site had to come into use, you'd > >> have a few minutes of recovery time while you replayed and caught up. > > > > Sounds perfectly reasonable. Not being able to do credit-card auth for 5 > > minutes will piss a bunch of people off, but losing actual data would be > > *really* bad. > > You might be mistaken in this point. Banks are like insurance companies. > The volume of financial transactions they process allows to evaluate the > cost to "secure" something vs. the possible damage if something is lost. > > Even 20 years ago the bank I was working for in Germany didn't bother to > compare the signatures on checks cashed at the counter if the amount was > under 1000 DM (about $400 US at that time). You could literally sign > your check with "Mickey Mouse" and go to any of the 250 locations and > you'd get cash for that check. The few cases where the bank had to > refund were far cheaper than checking every single signature.
There's a difference between someone getting spoofed when their checkbook got stolen and suddenly losing a bunch of CC transactions. Though, I wonder if CC machines ever double-check that transactions they've already submitted actually made it into the system... -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 _______________________________________________ Slony1-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/slony1-general
