Re: UUIDs in core WAS: 9.4 Proposal: Initdb creates a single table

On Thu, Apr 24, 2014 at 8:43 PM, Marti Raudsepp <marti(at)juffo(dot)org> wrote:

> On Fri, Apr 25, 2014 at 3:36 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Of course, the weak spot in this analysis is the assumption that there
> > are actually 122 independent bits in the value. It's not difficult to
> > imagine that systems with crummy random() implementations might only have
> > something like 32 bits worth of real randomness.
>
> Obviously you can't use random(). That's why I talked about
> cryptographic PRNGs, crypto libraries do proper seeding and generate
> reliably random numbers all the time.
>

... And we can't be certain that there won't be some internal
characteristic weakness.

Cryptography is *hard*; treating it as certainty that things will be gotten
correct
tends to be a foolish assumption.

Which is why UUID "type 1" resolves this by combining multiple sorts of
anti-correlations, the combination of:
a) Node-specific information (e.g. - in the standard form, parts of the MAC
address), so no collisions between node A and node B.
b) Timestamp, so that things that happen at different times will be kept
unique.
c) An extra sequence, so that if there are multiple events on the same node
at the same time, they *still* don't collide.

I trust the combination to work pretty well, and that's why it was designed
that way.

A RNG, however good, can't provide the same guarantees of lack of conflicts.
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"