On 09.01.22 01:38, Tom Lane wrote:
> 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 look forward to the new more database-friendly UUID versions being
standardized:
https://datatracker.ietf.org/doc/html/draft-peabody-dispatch-new-uuid-format-02
I don't think we need to do a lot of work in the meantime to rescue
obsolete UUID versions that no one really uses in practice, based on a
problem on one marginal platform.
