Re: UUIDs in core WAS: 9.4 Proposal: Initdb creates a single table - Mailing list pgsql-hackers

From Greg Stark
Subject Re: UUIDs in core WAS: 9.4 Proposal: Initdb creates a single table
Date
Msg-id CAM-w4HNM7pgS6P=mii1Er2gBg4YJirCDdJywpUPfK_RyQeOWnw@mail.gmail.com
Whole thread Raw
In response to Re: UUIDs in core WAS: 9.4 Proposal: Initdb creates a single table  (Marti Raudsepp <marti@juffo.org>)
Responses Re: UUIDs in core WAS: 9.4 Proposal: Initdb creates a single table
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: Composite Datums containing toasted fields are a bad idea(?)
Next
From: Tom Lane
Date:
Subject: Re: Composite Datums containing toasted fields are a bad idea(?)