X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id B8811D8967 for ; Tue, 6 Sep 2005 20:27:05 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 14863-10 for ; Tue, 6 Sep 2005 23:27:02 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by svr1.postgresql.org (Postfix) with ESMTP id A5AF8D84F0 for ; Tue, 6 Sep 2005 20:27:00 -0300 (ADT) Received: by rproxy.gmail.com with SMTP id 40so246629rnz for ; Tue, 06 Sep 2005 16:27:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Y5FGqg9dWZZGalwIm2AeVdnpv7oLb7zTafhEsmGnC3JssIH2LvRo48+11g0uwc+WnmwtxEq/cR/g4WuueDTq8/ZD9v+2Cm7+bVocZ7g1bVugsOJ7HIe6uiAy4155wa5md6MZtQ7KZDJGsDZvsW+GgsBozPLAHLO3z6vbWaxI2eU= Received: by 10.11.119.40 with SMTP id r40mr18168cwc; Tue, 06 Sep 2005 16:27:04 -0700 (PDT) Received: by 10.11.119.38 with HTTP; Tue, 6 Sep 2005 16:27:04 -0700 (PDT) Message-ID: <36e682920509061627570d03a0@mail.gmail.com> Date: Tue, 6 Sep 2005 18:27:04 -0500 From: "Jonah H. Harris" Reply-To: jonah.harris@gmail.com To: Bob Ippolito Subject: Re: uuid type for postgres Cc: mark@mark.mielke.cc, Tom Lane , josh@agliodbs.com, pgsql-hackers@postgresql.org, nathan wagner In-Reply-To: <75CDCC93-EF09-4ED5-9770-55F49BF48614@redivi.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3750_21941320.1126049224584" References: <20050906135057.GA24136@granicus.if.org> <20050906144930.GA27641@mark.mielke.cc> <200509061002.43803.josh@agliodbs.com> <36e6829205090612575b954f38@mail.gmail.com> <20050906203811.GA3069@mark.mielke.cc> <20921.1126043674@sss.pgh.pa.us> <20050906220648.GD3069@mark.mielke.cc> <75CDCC93-EF09-4ED5-9770-55F49BF48614@redivi.com> X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.454 required=5 tests=[AWL=-0.075, HTML_20_30=0.504, HTML_MESSAGE=0.001, RCVD_BY_IP=0.024] X-Spam-Level: X-Archive-Number: 200509/296 X-Sequence-Number: 72693 ------=_Part_3750_21941320.1126049224584 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Tom, you worded my thoughts much better than I did. Bob, I too had heard that host-based UUIDs/GUIDs had issues with uniqueness= .=20 I think Microsoft's implementation was hosed and they ended up eliminating= =20 using the MAC completely. I'll check out the code & get back. On 9/6/05, Bob Ippolito wrote: >=20 >=20 > On Sep 6, 2005, at 3:06 PM, mark@mark.mielke.cc wrote: >=20 > > On Tue, Sep 06, 2005 at 05:54:34PM -0400, Tom Lane wrote: > > > >> I don't see any "big opposition". People are simply questioning the > >> idea whether it belongs in core PG. The reason we don't want to > >> accept > >> everything-and-the-kitchen-sink in core is that we have only limited > >> manpower to maintain it. So you've got to justify that we should > >> spend > >> our effort here and not elsewhere. There's a fair amount of nearly > >> ... > >> been there awhile. So one of the questions that's going to be > >> asked is > >> how useful/popular it's really going to be. > >> > > > > Sounds reasonable, and certainly no more than I expected. If Nathan > > hadn't raised the issue, it probably would have been a few months > > before I raised it myself. > > > > > >> One thing that is raising my own level of concern quite a bit is the > >> apparent portability issues. Code that isn't completely portable > >> is a > >> huge maintainability problem; in particular, stuff that requires > >> system-dependent behavior used nowhere else in Postgres is a real > >> pain. > >> It sounds like the UUID code expects to be able to get at the > >> machine's > >> MAC address, which suggests serious issues in (a) relying on > >> not-too-standard APIs, (b) possible protection issues (will an > >> unprivileged process be able to get at the MAC address?), and (c) > >> ill-defined behavior on machines with more or less than one MAC > >> address. > >> Not to mention that MAC addresses aren't so unique as all that. > >> > > > > I'll try to prepare an answer for this. (I started to write a lot of > > information - but is it unverified from memory, and perhaps should be > > more authoritative before presented as truth) >=20 > Some modern UUID implementations prefer /dev/urandom or similar to > the time or MAC address unless you really beg them to give you a > weaker UUID. >=20 > You can take a look at the man page for the Theodore Y. Ts'o > implementation that is in Darwin's Libc here: > http://developer.apple.com/documentation/Darwin/Reference/ManPages/ > man3/uuid_generate.3.html >=20 > Specifically: >=20 > The uuid_generate function creates a new universally unique > identifier > (UUID). The uuid will be generated based on high-quality > randomness > from /dev/urandom, if available. If it is not > available, then > uuid_generate will use an alternative algorithm which uses > the current > time, the local ethernet MAC address (if available), and > random data > generated using a pseudo-random generator. >=20 > The Apache Portable Runtime has a apr_os_uuid_get() that supports two > flavors of UUID for unix (Linux/Mac OS X uuid_generate and FreeBSD's > uuid_create, may be available elsewhere), and the UuidCreate API on > Win32. apr-util's apr_uuid_get() will use apr_os_uuid_get() if > available, and otherwise will default to a relatively weak mostly- > timestamp-based UUID. >=20 > It would probably be reasonable and easy to do what Apache does > here. A platform UUID implementation, if present, is generally going > to be better than anything included into PostgreSQL itself. >=20 > -bob >=20 > ------=_Part_3750_21941320.1126049224584 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Tom, you worded my thoughts much better than I did.

Bob, I too had heard that host-based UUIDs/GUIDs had issues with uniqueness.  I think Microsoft's implementation was hosed and they ended up eliminating using the MAC completely.

I'll check out the code & get back.


On 9/6/05, Bob Ippolito <bob@redivi.co= m> wrote:

On Sep 6, 2005, at 3:06 PM, mark= @mark.mielke.cc wrote:

> On Tue, Sep 06, 2005 at 05:54:34PM -= 0400, Tom Lane wrote:
>
>> I don't see any "big opposit= ion".  People are simply questioning the
>> idea whether it belongs in core PG.  The reason we d= on't want to
>> accept
>> everything-and-the-kitchen-sink= in core is that we have only limited
>> manpower to maintain it.&= nbsp; So you've got to justify that we should
>> spend
>> our effort here and not elsewhere. &nbs= p;There's a fair amount of nearly
>> ...
>> been there aw= hile.  So one of the questions that's going to be
>> ask= ed is
>> how useful/popular it's really going to be.
>>
>
> Sounds reasonable, and certainly no more than = I expected. If Nathan
> hadn't raised the issue, it probably would ha= ve been a few months
> before I raised it myself.
>
>
>> One thing that is raising my own level of concern quite a bit = is the
>> apparent portability issues.  Code that isn't = completely portable
>> is a
>> huge maintainability probl= em; in particular, stuff that requires
>> system-dependent behavior used nowhere else in Postgres is a r= eal
>> pain.
>> It sounds like the UUID code expects to b= e able to get at the
>> machine's
>> MAC address, which s= uggests serious issues in (a) relying on
>> not-too-standard APIs, (b) possible protection issues (will an=
>> unprivileged process be able to get at the MAC address?), and = (c)
>> ill-defined behavior on machines with more or less than one= MAC
>> address.
>> Not to mention that MAC addresses aren't = so unique as all that.
>>
>
> I'll try to prepare an a= nswer for this. (I started to write a lot of
> information - but is i= t unverified from memory, and perhaps should be
> more authoritative before presented as truth)

Some modern U= UID implementations prefer /dev/urandom or similar to
the time or MAC ad= dress unless you really beg them to give you a
weaker UUID.

You c= an take a look at the man page for the Theodore Y. Ts'o
implementation that is in Darwin's Libc here:
http://developer.= apple.com/documentation/Darwin/Reference/ManPages/
man3/uuid_generat= e.3.html

Specifically:

       &nbs= p;The uuid_generate function creates a new universally unique
identifier=
        (UUID).   The  uuid  will be generated based on high-quality
r= andomness
        from &nbs= p;/dev/urandom,  if  available.   If  it  is  not
available,  then=
        uuid_generate &nbs= p;will use an alternative algorithm which uses
the current
 &nbs= p;      time, the local ethernet MAC address = (if available),  and
random  data
  &nb= sp;     generated using a pseudo-random generator.

The Apache Portable Runtime has a apr_os_uuid_get() that supports t= wo
flavors of UUID for unix (Linux/Mac OS X uuid_generate and FreeBSD's<= br>uuid_create, may be available elsewhere), and the UuidCreate API on
Win32.  apr-util's apr_uuid_get() will use apr_os_uuid_get() ifavailable, and otherwise will default to a relatively weak mostly-
tim= estamp-based UUID.

It would probably be reasonable and easy to do wh= at Apache does
here.  A platform UUID implementation, if present, is general= ly going
to be better than anything included into PostgreSQL itself.
=
-bob


------=_Part_3750_21941320.1126049224584--