Re: BUG #17358: While using --with-uuid=bsd option, uuid_ossp test fails on NetBSD 9.2

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.