From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Garick Hamlin <ghamlin(at)isc(dot)upenn(dot)edu> |
Cc: | 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-10-31 19:42:33 |
Message-ID: | CA+TgmobKPQYx6G1y18cMgphzpe2FhPhZ04Z_TaUYR3K84F7ppw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Payal Singh | 2013-10-31 19:49:06 | Review: Patch FORCE_NULL option for copy COPY in CSV mode |
Previous Message | Robert Haas | 2013-10-31 19:33:53 | Re: API bug in DetermineTimeZoneOffset() |