Re: How can I build OSSP UUID support on Windows to avoid duplicate UUIDs?

From: Christopher Browne <cbbrowne(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Garick Hamlin <ghamlin(at)isc(dot)upenn(dot)edu>, MauMau <maumau307(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Hiroshi Saito <hiroshi(at)winpg(dot)jp>, Dave Page <dpage(at)pgadmin(dot)org>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: How can I build OSSP UUID support on Windows to avoid duplicate UUIDs?
Date: 2013-11-04 18:49:59
Message-ID: CAFNqd5VwTG+WckOBSvNopP1u_9vFHKFXHMyMxTUOghPiEj3H+g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Oct 31, 2013 at 3:42 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Thu, Oct 31, 2013 at 2:44 PM, Garick Hamlin <ghamlin(at)isc(dot)upenn(dot)edu>
wrote:
>> I think using /dev/urandom directly would be surprising. At least it
would
>> have probably have taken me a while to figure out what was depleting the
>> entropy pool here.
>
> Perhaps so; a bigger problem IMHO is that it's not portable. I think
> the only way to solve this problem is to import (or have an option to
> link with) a strong, sophisticated PRNG with much larger internal
> state than pg_lrand48, which uses precisely 48 bits of internal state.
> For this kind of thing, I'm fairly sure that we need something with
> at least 128 bits of internal state (as wide as the random value we
> want to generate) and I suspect it might be advantageous to have
> something a whole lot wider, maybe a few kB.

I mentioned the notion of building an entropy pool, into which one might
add various sorts of random inputs, under separate cover...

The last time I had need of a rather non-repeating RNG, I went with
a Fibonacci-based one, namely Mersenne Twister...

<http://en.wikipedia.org/wiki/Mersenne_twister>

The sample has 624 integers (presumably that means 624x32 bits) as
its internal state. Apparently not terribly suitable for cryptographic
purposes,
but definitely highly non-repetitive, which is what we're notably
worried about for UUIDs.
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2013-11-04 19:21:55 Re: pgsql: Remove internal uses of CTimeZone/HasCTZSet.
Previous Message Robert Haas 2013-11-04 17:07:07 Re: Removal of archive in wal_level