wmoran@xxxxxxxxxxxxxxxxx (Bill Moran) writes: > If the chance of a duplicate is 1 in a hundred gazillion, then I can > still hit a dupe the VERY FIRST TIME I USE IT. > > I'm writing software that is intended to be used to save lives in the > event of an earthquake or flood or cosmic ray flipping bits or any > other massive disaster. The last thing I need while a bunch of EMTs > are digging bodies out of the rubble trying to save their lives is to > need to resolve a key conflict with a bunch of mobile devices, most of > which are not reachable because the cell network is down because of > the disaster. There's going to be enough other shit going wrong ... > my software is supposed to be part of the solution. > > I don't give a fuck how small the chance of conflict is, the only > viable option for that chance is 0. Period. Any argument to the > contrary is stupid, asinine and outright negligent. If your system is sufficiently negligently designed that this particular conflict causes it to kill people, then I wouldn't be too inclined to point at this issue with UUIDs being the Real Problem with the system. This is NOT the only risk that the system faces; you can't get *nearly* as low probabilities attached to hardware and network issues such as: - Disks failing - Cosmic rays twiddling bits in memory - Network connections failing part way through the work - Dumb techs blindly cloning the same "host key" onto every one of the EMTs' data collection devices That last item is an argument in *FAVOR* of using UUIDs for the "EMTs digging bodies out of rubble" scenario... The typical alternative to UUIDs would be to have (Sequence + Host Data), and I'd expect there to be a considerable risk of Dumb Techs making mistakes there. It wouldn't be difficult for such a scenario to induce systematic key collisions. It's never just about one risk; it's about *all the risks.* > And that's been my point all along, despite people trying to dilute it > with nonsense numbers that they don't understand: UUIDs are sufficiently > unique for 99.99999999999% of the applications out there. However, you > should always take 5 or 10 minutes to consider whether your application > is one of the .00000000001% that can't tolerate the tiny risk. If your application is so fragile that it cannot tolerate *that* tiny risk, then I have to wonder if your system isn't Just Plain Too Fragile, because there are other unavoidable risks likely to be of much greater probability. -- "Have you noticed that, when we were young, we were told that `everybody else is doing it' was a really stupid reason to do something, but now it's the standard reason for picking a particular software package?" -- Barry Gehm -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
