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

mark@mark.mielke.cc wrote:
> On Tue, Sep 19, 2006 at 11:21:51PM -0400, Alvaro Herrera wrote:
>> mark@mark.mielke.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@mark.mielke.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