From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: byavuz81@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17358: While using --with-uuid=bsd option,
 uuid_ossp test fails on NetBSD 9.2
In-reply-to: <20220108204528.f7viwyuxamdm2n34@alap3.anarazel.de>
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>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Sat, 08 Jan 2022 12:45:28 -0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1588970.1641677131.1@sss.pgh.pa.us>
Date: Sat, 08 Jan 2022 16:25:31 -0500
Message-ID: <1588971.1641677131@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1588971.1641677131%40sss.pgh.pa.us>
Precedence: bulk

Andres Freund <andres@anarazel.de> writes:
> On 2022-01-08 15:35:33 -0500, Tom Lane wrote:
>> (I think v1 UUID uniqueness is snake-oil anyway, so I'm just thinking of
>> choosing a random "clock sequence" in each process and calling it good.)

> Hm. Not so sure about that... If we go there, why don't we just rip out the
> ability to create v1 UUIDs?

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.

And, of course, the reason that the whole thing is snake oil is that
global uniqueness of MAC addresses is a fiction.  I think it probably
was from the get-go, but in these days of MAC addresses being just
made up on the fly, it certainly is.  (Need I mention macaddr8, and
the lack of space for it in v1 UUIDs?)

So maybe what we should really do is follow the lead of NetBSD
(and OpenBSD too, it seems) and just desupport v1 UUID.  That
still leaves us with two alternatives: throw error, or silently
hand back a v4 UUID instead, as they're doing.

But I don't especially like that, because v4 UUIDs are pretty
index-unfriendly, more so than v1 anyway.  I'd rather continue
to support v1 to the extent we can practically do so.

			regards, tom lane