Re: How can I build OSSP UUID support on Windows to avoid duplicate UUIDs? - Mailing list pgsql-hackers

From Christopher Browne
Subject Re: How can I build OSSP UUID support on Windows to avoid duplicate UUIDs?
Date
Msg-id CAFNqd5VwTG+WckOBSvNopP1u_9vFHKFXHMyMxTUOghPiEj3H+g@mail.gmail.com
Whole thread Raw
In response to Re: How can I build OSSP UUID support on Windows to avoid duplicate UUIDs?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: How can I build OSSP UUID support on Windows to avoid duplicate UUIDs?  (高增琦 <pgf00a@gmail.com>)
List pgsql-hackers
<p dir="ltr">On Thu, Oct 31, 2013 at 3:42 PM, Robert Haas <<a
href="mailto:robertmhaas@gmail.com">robertmhaas@gmail.com</a>>wrote:<br /> > On Thu, Oct 31, 2013 at 2:44 PM,
GarickHamlin <<a href="mailto:ghamlin@isc.upenn.edu">ghamlin@isc.upenn.edu</a>> wrote:<br /> >> I think
using/dev/urandom directly would be surprising. At least it would<br /> >> have probably have taken me a while to
figureout what was depleting the<br /> >> entropy pool here.<br /> ><br /> > Perhaps so; a bigger problem
IMHOis that it's not portable. I think<br /> > the only way to solve this problem is to import (or have an option
to<br/> > link with) a strong, sophisticated PRNG with much larger internal<br /> > state than pg_lrand48, which
usesprecisely 48 bits of internal state.<br /> > For this kind of thing, I'm fairly sure that we need something
with<br/> > at least 128 bits of internal state (as wide as the random value we<br /> > want to generate) and I
suspectit might be advantageous to have<br /> > something a whole lot wider, maybe a few kB.<p dir="ltr">I mentioned
thenotion of building an entropy pool, into which one might<br /> add various sorts of random inputs, under separate
cover...<pdir="ltr">The last time I had need of a rather non-repeating RNG, I went with<br /> a Fibonacci-based one,
namelyMersenne Twister...<p dir="ltr"><<a
href="http://en.wikipedia.org/wiki/Mersenne_twister">http://en.wikipedia.org/wiki/Mersenne_twister</a>><p
dir="ltr">Thesample has 624 integers (presumably that means 624x32 bits) as<br /> its internal state. Apparently not
terriblysuitable for cryptographic purposes,<br /> but definitely highly non-repetitive, which is what we're notably<br
/>worried about for UUIDs.<br /> -- <br /> When confronted by a difficult problem, solve it by reducing it to the<br />
question,"How would the Lone Ranger handle this?" 

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Removal of archive in wal_level
Next
From: Noah Misch
Date:
Subject: Re: pgsql: Remove internal uses of CTimeZone/HasCTZSet.