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: <20220108200643.2ufdoxj5gdfvrrdg@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>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Sat, 08 Jan 2022 12:06:43 -0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1584604.1641674133.1@sss.pgh.pa.us>
Date: Sat, 08 Jan 2022 15:35:33 -0500
Message-ID: <1584605.1641674133@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1584605.1641674133%40sss.pgh.pa.us>
Precedence: bulk

Andres Freund <andres@anarazel.de> writes:
> On 2022-01-08 14:59:56 -0500, Tom Lane wrote:
>> Right, I was planning to have a look at how they'd done it.  The BSD
>> implementation seems to be inside the kernel, so that's not likely
>> to be helpful, but the other two must be in userspace.

> https://github.com/tytso/e2fsprogs/blob/master/lib/uuid/gen_uuid.c#L240
> https://github.com/sean-/ossp-uuid/blob/master/uuid_mac.c#L92

Thanks for the pointers!  I was hoping for a Windows version, but
neither one seems to cover that.  OTOH, that means that we can't
build uuid-ossp on Windows today anyway, so failing to support it
makes things no worse than before ... and anybody who wants that
can always send a patch.

Before I start writing code, there seem to be two possible approaches
here:

1. Rip out all the external-library dependencies, lock stock and
barrel.  contrib/uuid-ossp is always built.  --with-uuid configure
argument becomes a no-op or an error.

2. contrib/uuid-ossp is always built, but if you say --with-uuid
then the existing code for that library is used.  We fall back to
homegrown code if you didn't say --with-uuid.

The main argument for #2 would be to preserve bug compatibility with
the existing behavior, in case (say) we pick a different interface's
MAC address than you got before.  I suppose also it's possible that
the existing libraries try harder to avoid collisions across UUIDs
generated in different processes than I envision doing in our own
version.  (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.)

Whether these are good enough reasons to continue carrying all
that code is unclear to me.  Thoughts?

			regards, tom lane