Thread

  1. Re: Re: 7.2 items

    Hannu Krosing <hannu@tm.ee> — 2001-05-14T05:30:45Z

    Franck Martin wrote:
    > 
    > I think OID should be truly unique in the world as to make it easier for
    > replication. If OID are real unique number (not in a table, not in a
    > database, but in the world) then replication can be easily built with
    > OIDs...
    > 
    
    Exactly! That is what the Mariposa project did - they made OIDs uniqe
    and 
    consisting of 32bit site id + 32bit local OID. I guess this could be
    split 
    some other way too, like 20 bit site id + 44bit local or any other.
    
    IMHO the best would be a scheme of 32bit site id + 32bit local, but each 
    site can get additional site ids from some central (for a supersite)
    table 
    when it sees that it is near runnig out of oids.
    
    -----------------------
    Hannu
    
    
  2. RE: Re: 7.2 items

    Franck Martin <franck@sopac.org> — 2001-05-14T05:34:02Z

    I think OID should be truly unique in the world as to make it easier for
    replication. If OID are real unique number (not in a table, not in a
    database, but in the world) then replication can be easily built with
    OIDs...
    
    Cheers.
    
    Franck Martin
    Network and Database Development Officer
    SOPAC South Pacific Applied Geoscience Commission
    Fiji
    E-mail: franck@sopac.org <mailto:franck@sopac.org> 
    Web site: http://www.sopac.org/
    <http://www.sopac.org/> Support FMaps: http://fmaps.sourceforge.net/
    <http://fmaps.sourceforge.net/> 
    
    This e-mail is intended for its addresses only. Do not forward this e-mail
    without approval. The views expressed in this e-mail may not be necessarily
    the views of SOPAC.
    
    
    
    -----Original Message-----
    From: Lincoln Yeoh [mailto:lyeoh@pop.jaring.my]
    Sent: Monday, 14 May 2001 3:45 
    To: Bruce Momjian; PostgreSQL-development
    Subject: [HACKERS] Re: 7.2 items
    
    
    At 01:20 PM 10-05-2001 -0400, Bruce Momjian wrote:
    >Here is a small list of big TODO items.  I was wondering which ones
    >people were thinking about for 7.2?
    >
    >---------------------------------------------------------------------------
    
    
    
    4) Not really important to me but can serial be a proper type or something
    so that drop table will drop the linked sequence as well? 
    Maybe:
     serial = old serial for compatibility
     serial4 = new serial
     serial8 = new serial using bigint
    (OK so 2 billion is big, but...)
    
    5) How will the various rollovers be handled e.g. OID, TID etc? What
    happens if OIDs are not unique? As things get faster and bigger a nonunique
    OID in a table might just happen.
    
    Cheerio,
    Link.
    
    
    ---------------------------(end of broadcast)---------------------------
    TIP 3: if posting/reading through Usenet, please send an appropriate
    subscribe-nomail command to majordomo@postgresql.org so that your
    message can get through to the mailing list cleanly
    
    
  3. Re: Re: 7.2 items

    Franck Martin <franck@sopac.org> — 2001-05-14T11:01:23Z

    Hannu Krosing wrote:
    
    > Franck Martin wrote:
    > >
    > > I think OID should be truly unique in the world as to make it easier for
    > > replication. If OID are real unique number (not in a table, not in a
    > > database, but in the world) then replication can be easily built with
    > > OIDs...
    > >
    >
    > Exactly! That is what the Mariposa project did - they made OIDs uniqe
    > and
    > consisting of 32bit site id + 32bit local OID. I guess this could be
    > split
    > some other way too, like 20 bit site id + 44bit local or any other.
    >
    > IMHO the best would be a scheme of 32bit site id + 32bit local, but each
    > site can get additional site ids from some central (for a supersite)
    > table
    > when it sees that it is near runnig out of oids.
    >
    > -----------------------
    > Hannu
    
    As I'm thinking about it there is a utility called uuidgen which generates
    such numbers.
    
    On my Mandrake distro it is part of the e2fsprogs package. Orbit uses it to
    generate unique numbers too.
    
    --------------
    The  uuidgen  program creates a new universally unique identifier (UUID)
    using the libuuid(3)
           library.  The new UUID can reasonably be considered unique among all
    UUIDs  created  on  the
           local system, and among UUIDs created on other systems in the past and
    in the future.
    
           There  are two types of UUID's which uuidgen can generate: time-based
    UUID's and random-based
           UUID's.  By default uuidgen will generate a random-based UUID if a
    high-quality random number
           generator  is  present.  Otherwise, it will chose a time-based UUID.
    It is possible to force
           the generation of one of these two UUID types by using the -r or -t
    options.
    
     The   UUID   of   the   form   1b4e28ba-2fa1-11d2-883f-b9a761bde3fb   (in
    printf(3)  format
           "%08x-%04x-%04x-%04x-%012x") is output to the standard output.
    -------------------
    
    Cheers.
    Franck@sopac.org
    
    
    
  4. Re: Re: 7.2 items

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-05-14T14:39:34Z

    Franck Martin <franck@sopac.org> writes:
    > The  uuidgen  program creates a new universally unique identifier (UUID)
    > using the libuuid(3)
    >        library.  The new UUID can reasonably be considered unique among all
    > UUIDs  created  on  the
    >        local system, and among UUIDs created on other systems in the past and
    > in the future.
    
    "Reasonably considered"?
    
    In other words, this is a 64-bit random number generator.  Sorry, I
    think the odds of collision would be uncomfortably high if we were to
    use such a thing for OIDs ... certainly so on installations that are
    worried about running out of 32-bit OIDs.  It sounds to me like uuidgen
    is built on the assumption that only relatively small numbers of IDs
    will be demanded from it.
    
    			regards, tom lane
    
    
  5. Re: Re: 7.2 items

    Gilles Darold <gilles@darold.net> — 2001-05-14T15:03:18Z

    Franck Martin wrote:
    
    > I think OID should be truly unique in the world as to make it easier for
    > replication. If OID are real unique number (not in a table, not in a
    > database, but in the world) then replication can be easily built with
    > OIDs...
    
    The Apache server has a UNIQUE_ID implementation and it is really
    unique in the world, I use it for my web apps. Their implementation
    is really simple an works fine. It is 19 alphanumeric bytes long.
    
    Regards,
    
    
    
    
  6. Re: Re: 7.2 items

    Ian Lance Taylor <ian@airs.com> — 2001-05-14T17:21:03Z

    Tom Lane <tgl@sss.pgh.pa.us> writes:
    
    > Franck Martin <franck@sopac.org> writes:
    > > The  uuidgen  program creates a new universally unique identifier (UUID)
    > > using the libuuid(3)
    > >        library.  The new UUID can reasonably be considered unique among all
    > > UUIDs  created  on  the
    > >        local system, and among UUIDs created on other systems in the past and
    > > in the future.
    > 
    > "Reasonably considered"?
    > 
    > In other words, this is a 64-bit random number generator.  Sorry, I
    > think the odds of collision would be uncomfortably high if we were to
    > use such a thing for OIDs ... certainly so on installations that are
    > worried about running out of 32-bit OIDs.  It sounds to me like uuidgen
    > is built on the assumption that only relatively small numbers of IDs
    > will be demanded from it.
    
    uuidgen with the -t option generates a UUID which includes the current
    time and the Ethernet hardware address.  The value is about as
    globally unique as it is possible to create in 128 bits.  The same
    algorithm is used by DCE, and a variant is used by DCOM.  To be used
    properly, you need to coordinate on one machine to ensure that
    different processes on that machine don't generate the same UUID.
    
    Here is a description:
        http://www.opengroup.org/onlinepubs/9629399/apdxa.htm#tagcjh_20
    
    Ian