Message-ID: <20727828-66c0-19d8-4b75-ce3ff12bf990@enterprisedb.com>
Date: Wed, 12 Jan 2022 12:12:24 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.4.1
Subject: Re: BUG #17358: While using --with-uuid=bsd option, uuid_ossp test
 fails on NetBSD 9.2
Content-Language: en-US
To: Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@anarazel.de>
Cc: byavuz81@gmail.com, pgsql-bugs@lists.postgresql.org
References: <17358-89806e7420797025@postgresql.org>
 <1377833.1641588532@sss.pgh.pa.us>
 <20220108194454.kl477tb6km6tyj5r@alap3.anarazel.de>
 <1581508.1641671996@sss.pgh.pa.us>
 <20220108200643.2ufdoxj5gdfvrrdg@alap3.anarazel.de>
 <1584605.1641674133@sss.pgh.pa.us>
 <20220108204528.f7viwyuxamdm2n34@alap3.anarazel.de>
 <1588971.1641677131@sss.pgh.pa.us> <1605935.1641688721@sss.pgh.pa.us>
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
In-Reply-To: <1605935.1641688721@sss.pgh.pa.us>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/20727828-66c0-19d8-4b75-ce3ff12bf990%40enterprisedb.com>
Precedence: bulk

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.