I wrote:
> Well, maybe. Just considering having our own generator already puts us
> in a state of sin, because the whole argument for v1 UUID uniqueness
> hinges on there being just one generator per machine (or per MAC
> address, anyway). As soon as there are independent generators using
> the same MAC address, they can't positively guarantee uniqueness.
> My thought about it is that once you've crossed that boundary, allowing
> each process to generate UUIDs independently is not much of a leap.
After a bit of further thought, it seems like a reasonable compromise
could be to move the code into core PG and maintain the UUID assignment
state in shared memory. We'd still set the clock sequence number to
something random at shmem initialization, but thereafter all backends
would draw from that shared state, allowing us to provide a guarantee
of uniqueness across the PG instance rather than just per-process.
(I don't see any value in trying to preserve the clock sequence number
across restarts. A restart should take long enough that the timestamp
will advance, making it moot. The main value of the clock sequence number
is to make it less likely that we'll generate the same UUID as some other
generator running on the same machine, so a random choice seems optimal.)
regards, tom lane
