pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: byavuz81@gmail.com
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17358: While using --with-uuid=bsd option, uuid_ossp test fails on NetBSD 9.2
Date: Wed, 12 Jan 2022 12:12:24 +0100
Message-ID: <20727828-66c0-19d8-4b75-ce3ff12bf990@enterprisedb.com> (raw)
In-Reply-To: <1605935.1641688721@sss.pgh.pa.us>
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>

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.





view thread (13+ messages)

Message-ID: <20727828-66c0-19d8-4b75-ce3ff12bf990@enterprisedb.com>
Permalink:  ../20727828-66c0-19d8-4b75-ce3ff12bf990@enterprisedb.com/
Also on:    postgresql.org/message-id/20727828-66c0-19d8-4b75-ce3ff12bf990@enterprisedb.com

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-bugs@postgresql.org
  Cc: peter.eisentraut@enterprisedb.com, tgl@sss.pgh.pa.us, andres@anarazel.de, 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: <20727828-66c0-19d8-4b75-ce3ff12bf990@enterprisedb.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox