Re: BUG #17358: While using --with-uuid=bsd option, uuid_ossp test fails on NetBSD 9.2
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: byavuz81@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2022-01-08T21:25:31Z
Lists: pgsql-bugs
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
Commits
-
Reject bogus output from uuid_create(3).
- e55ccb3b179c 14.6 landed
- c4b6d218e369 16.0 landed
- a61095aa7946 13.9 landed
- 95028d9de422 10.23 landed
- 4d3f54bd7a0d 11.18 landed
- 23fe89a61223 12.13 landed
- 100a8ca2c285 15.0 landed