On Fri, Apr 25, 2014 at 8:58 PM, Josh Berkus j...@agliodbs.com wrote:
Well, I've already had collisions with UUID-OSSP, in production, with
only around 20 billion values. So clearly there aren't 122bits of true
randomness in OSSP. I can't speak for other implementations because I
haven't
On Fri, Apr 25, 2014 at 04:18:18PM +0100, Greg Stark wrote:
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
Martijn van Oosterhout klep...@svana.org writes:
On Fri, Apr 25, 2014 at 04:18:18PM +0100, Greg Stark wrote:
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
On 04/26/2014 11:18 AM, Tom Lane wrote:
It's worth noting in this connection that we've never tried hard to ensure
that database identifiers are actually unique. One potentially serious
issue is that slave servers will have the same identifier as their master.
Yeah, this is one of those
On 04/25/2014 11:46 AM, David Fetter wrote:
On Fri, Apr 25, 2014 at 10:58:29AM -0700, Josh Berkus wrote:
You may say oh, that's not the job of the identifer, but if it's not,
WTF is the identifer for, then?
Frequently, it's to provide some kind of opacity in the sense of not
have an obvious
On 4/25/14, 12:58 PM, Josh Berkus wrote:
Well, I've already had collisions with UUID-OSSP, in production, with
only around 20 billion values. So clearly there aren't 122bits of true
randomness in OSSP. I can't speak for other implementations because I
haven't tried them.
Or perhaps you
On Sat, Apr 26, 2014 at 8:58 PM, Josh Berkus j...@agliodbs.com wrote:
However, there's a fundamental problem with the concept of the dataset
ID in that there's absolutely no way for PostgreSQL to know when it has
a unique dataset. Consider a downtime database file cloning for
example; the two
On Fri, Apr 25, 2014 at 1:43 AM, Marti Raudsepp ma...@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
On 04/24/2014 05:23 PM, Marti Raudsepp wrote:
On Thu, Apr 24, 2014 at 8:40 PM, Josh Berkus j...@agliodbs.com wrote:
A pseudo-random UUID is frankly pretty
useless to me because (a) it's not really unique
This is FUD. A pseudorandom UUID contains 122 bits of randomness. As
long as you can
On Fri, Apr 25, 2014 at 10:58:29AM -0700, Josh Berkus wrote:
On 04/24/2014 05:23 PM, Marti Raudsepp wrote:
On Thu, Apr 24, 2014 at 8:40 PM, Josh Berkus j...@agliodbs.com wrote:
A pseudo-random UUID is frankly pretty
useless to me because (a) it's not really unique
This is FUD. A
Alvaro,
I don't understand your point. I'm only replying to Tom's assertion
that UUID generation might not be all that unique after all (or, in
other words, AIUI, that the universally unique part of the name is
wishful thinking and not an actual property of the real thing.)
Oh, I think I
Last year, I built a pl/pgsql generator of version 1-ish UUIDs, which
would combine timestamps with local information to construct data that kind
of emulated the timestamp+MAC address that is version #1 of UUID.
Note that there are several versions of UUIDs:
1. Combines MAC address, timestamp,
On Thu, Apr 24, 2014 at 8:40 PM, Josh Berkus j...@agliodbs.com wrote:
A pseudo-random UUID is frankly pretty
useless to me because (a) it's not really unique
This is FUD. A pseudorandom UUID contains 122 bits of randomness. As
long as you can trust the random number generator, the chances of a
Marti Raudsepp ma...@juffo.org writes:
On Thu, Apr 24, 2014 at 8:40 PM, Josh Berkus j...@agliodbs.com wrote:
A pseudo-random UUID is frankly pretty
useless to me because (a) it's not really unique
This is FUD. A pseudorandom UUID contains 122 bits of randomness. As
long as you can trust the
On Fri, Apr 25, 2014 at 3:36 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Of course, the weak spot in this analysis is the assumption that there
are actually 122 independent bits in the value. It's not difficult to
imagine that systems with crummy random() implementations might only have
something
On Thu, Apr 24, 2014 at 8:43 PM, Marti Raudsepp ma...@juffo.org wrote:
On Fri, Apr 25, 2014 at 3:36 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Of course, the weak spot in this analysis is the assumption that there
are actually 122 independent bits in the value. It's not difficult to
imagine
16 matches
Mail list logo
