Re: [PATCHES] Patch for UUID datatype (beta)

From: Thomas Hallgren <thomas(at)tada(dot)se>
To: pgsql-hackers(at)postgresql(dot)org
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: [PATCHES] Patch for UUID datatype (beta)
Date: 2006-09-27 20:00:59
Message-ID: 451AD87B.8000005@tada.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

mark(at)mark(dot)mielke(dot)cc wrote:
> On Tue, Sep 19, 2006 at 11:21:51PM -0400, Alvaro Herrera wrote:
>> mark(at)mark(dot)mielke(dot)cc wrote:
>>> On Tue, Sep 19, 2006 at 08:20:13AM -0500, Jim C. Nasby wrote:
>>>> On Mon, Sep 18, 2006 at 07:45:07PM -0400, mark(at)mark(dot)mielke(dot)cc wrote:
>>>>> I would not use a 100% random number generator for a UUID value as was
>>>>> suggested. I prefer inserting the MAC address and the time, to at
>>>>> least allow me to control if a collision is possible. This is not easy
>>>>> to do using a few lines of C code. I'd rather have a UUID type in core
>>>>> with no generation routine, than no UUID type in core because the code
>>>>> is too complicated to maintain, or not portable enough.
>>>> As others have mentioned, using MAC address doesn't remove the
>>>> possibility of a collision.
>>> It does, as I control the MAC address.
>> What happens if you have two postmaster running on the same machine?
>
> Could be bad things. :-)
>
> For the case of two postmaster processes, I assume you mean two
> different databases? If you never intend to merge the data between the
> two databases, the problem is irrelevant. There is a much greater
> chance that any UUID form is more unique, or can be guaranteed to be
> unique, within a single application instance, than across all
> application instances in existence. If you do intend to merge the
> data, you may have a problem.
>
You may. But it's not very likely. Since a) there is a 13-bit random number in addition to
the MAC address (the clock sequence) and b) the timestamp has a granularity of 100 nanosec.
An implementation could be made to prevent clock-sequence collisions on the same machine and
thereby avoid this altogether.

Kind Regards,
Thomas Hallgren

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim C. Nasby 2006-09-27 20:10:20 Re: [Pgbuildfarm-members] Buildfarm alarms
Previous Message Andrew Dunstan 2006-09-27 19:16:52 Re: Buildfarm & cvsignore files

Browse pgsql-patches by date

  From Date Subject
Next Message mark 2006-09-27 23:26:40 Re: Faster StrNCpy
Previous Message Strong, David 2006-09-27 14:08:05 Re: Faster StrNCpy