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 17:59:04 |
Message-ID: | CA+TgmoamPPkv41L7C_tpAgXv+49OmaRjab3BF35-YpDgxAihrg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Oct 31, 2013 at 1:02 PM, Garick Hamlin <ghamlin(at)isc(dot)upenn(dot)edu> wrote:
> On Thu, Oct 31, 2013 at 09:54:14PM +0900, MauMau wrote:
>> From: "Robert Haas" <robertmhaas(at)gmail(dot)com>
>>> ISTM that the biggest problem is that we don't have a random number
>>> generator which generates enough bits of randomness to implement
>>> uuid_generate_v3. I think relatively few people would cry if we
>>> didn't support uuid_generate_v1(), and the others all look simple
>>> enough, provided there's somewhere to get lots of random bits.
>>>
>>> On Linux, it seems like we could get those bits from /dev/urandom,
>>> though I'm not sure how efficient that would be for the case where
>>> many UUIDs are being generated at once. But that wouldn't be very
>>> portable. It's tempting to think that we'd need a PRNG that generates
>>> wider values, for which we might find other application also. But I'm
>>> not volunteering to be the one to create such a thing.
>>
>> OpenSSL provides rand_bytes() which generates random bytes of any length.
>> It uses /dev/urandom or /dev/random on UNIX/Linux and Crypto API of
>> Microsoft on Windows.
>
> What about using a cipher here as the PRNG? It seems like using openssl
> rand_bytes() to seed aes in ctr would work ok without starving the system of
> entropy when making a lot of uuids.
There are two good reasons for us NOT to rely on OpenSSL:
1. Not all builds are done --with-openssl.
2. OpenSSL is rickety and poorly-documented, and depending on it for
more things will surely increase the pain we suffer on some great
future day when we begin supporting some other SSL library alongside
it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2013-10-31 18:02:03 | Re: pg_fallocate |
Previous Message | Robert Haas | 2013-10-31 17:42:12 | Re: Add accurate option to pgbench |