Re: How can I build OSSP UUID support on Windows to avoid duplicate UUIDs?
От | Robert Haas |
---|---|
Тема | Re: How can I build OSSP UUID support on Windows to avoid duplicate UUIDs? |
Дата | |
Msg-id | CA+TgmoamPPkv41L7C_tpAgXv+49OmaRjab3BF35-YpDgxAihrg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: How can I build OSSP UUID support on Windows to avoid duplicate UUIDs? (Garick Hamlin <ghamlin@isc.upenn.edu>) |
Ответы |
Re: How can I build OSSP UUID support on Windows to
avoid duplicate UUIDs?
|
Список | pgsql-hackers |
On Thu, Oct 31, 2013 at 1:02 PM, Garick Hamlin <ghamlin@isc.upenn.edu> wrote: > On Thu, Oct 31, 2013 at 09:54:14PM +0900, MauMau wrote: >> From: "Robert Haas" <robertmhaas@gmail.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
В списке pgsql-hackers по дате отправления: