Re: UUIDs in core WAS: 9.4 Proposal: Initdb creates a single table

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: UUIDs in core WAS: 9.4 Proposal: Initdb creates a single table
Дата
Msg-id CAM-w4HNM7pgS6P=mii1Er2gBg4YJirCDdJywpUPfK_RyQeOWnw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: UUIDs in core WAS: 9.4 Proposal: Initdb creates a single table  (Marti Raudsepp <marti@juffo.org>)
Ответы Re: UUIDs in core WAS: 9.4 Proposal: Initdb creates a single table  (Martijn van Oosterhout <kleptog@svana.org>)
Список pgsql-hackers
On Fri, Apr 25, 2014 at 1:43 AM, Marti Raudsepp <marti@juffo.org> wrote:
> Obviously you can't use random(). That's why I talked about
> cryptographic PRNGs, crypto libraries do proper seeding and generate
> reliably random numbers all the time.


The difficulty lies not really in the PRNG implementation (which is
hard but well enough understood that it's not much of an issue these
days). The difficulty lies in obtaining enough entropy. There are ways
of obtaining enough entropy and they are available. But they're not
free.

Obtaining enough entropy requires access to hardware devices which
means a kernel system call. Kernel system calls are relatively slow
when you're talking about generating sequential IDs. They also deplete
the available entropy pool for other sources which may means they have
security consequences.

Which isn't to say they're a bad idea but like everything else in
engineering there are tradeoffs and no such thing as a free lunch.
You can avoid depleting the entropy pool by including data you expect
to be unique as a kind of fake entropy -- which quickly gets you back
to looking for things like MAC address to avoid duplicates across
systems.

-- 
greg



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Composite Datums containing toasted fields are a bad idea(?)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Composite Datums containing toasted fields are a bad idea(?)