Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n6Hsh-0001pE-Ls for pgsql-bugs@arkaria.postgresql.org; Sat, 08 Jan 2022 20:00:03 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1n6Hsg-0006eb-3U for pgsql-bugs@arkaria.postgresql.org; Sat, 08 Jan 2022 20:00:02 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n6Hsf-0006eC-SE for pgsql-bugs@lists.postgresql.org; Sat, 08 Jan 2022 20:00:01 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n6Hsd-0002uJ-KZ for pgsql-bugs@lists.postgresql.org; Sat, 08 Jan 2022 20:00:00 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 208JxudT1581509; Sat, 8 Jan 2022 14:59:56 -0500 From: Tom Lane To: Andres Freund 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: <20220108194454.kl477tb6km6tyj5r@alap3.anarazel.de> References: <17358-89806e7420797025@postgresql.org> <1377833.1641588532@sss.pgh.pa.us> <20220108194454.kl477tb6km6tyj5r@alap3.anarazel.de> Comments: In-reply-to Andres Freund message dated "Sat, 08 Jan 2022 11:44:54 -0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1581507.1641671996.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Sat, 08 Jan 2022 14:59:56 -0500 Message-ID: <1581508.1641671996@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Andres Freund writes: > On 2022-01-07 15:48:52 -0500, Tom Lane wrote: >> Not sure about how to fix this nicely. We've tried to avoid >> writing our own code for V1 UUIDs, but maybe we should just >> bite the bullet and do that? > It might be the most reasonable approach. We certainly seem to have spen= t at > least as much effort avoiding our own implementation than implementing i= t > ourselves. Yeah, exactly :-(. Other than finding a MAC address, it doesn't seem like there's much there, and we've spent an awful lot of work on supporting N different libraries for this. > We could grab it from ossp-uuid or e2fs - both seem to be compatibly lic= ensed? 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. regards, tom lane