Re: PATCH: Postgresql Patch

Hi Enver,


Enver ALTIN schrieb:
> I guess this may wreak havoc if someone insane decides to connect 
> multiple bearerbox instances to a single database server, because there 
> is little chance that two different bearerbox instances creating a 
> not-so-universally-unique-ID that may clash.

this is not true. UUID is to 99% unique even in a cluster. We have log 
tabel in the DB with over 500K inserts per day and UUID will be 
generated not only by one instance and I never seen clash since 2years.

> 
> Personally I like the serial column approach.
> 
> -HTH
> 
> On Tue, Jun 24, 2008 at 12:45 PM, Alexander Malysh <[email protected] 
> <mailto:[email protected]>> wrote:
> 
>     Hi,
> 
>     would it not be easier to use our UUID instead? I have patch in my
>     tree,  will try to extract it...
> 
>     Thanks,
>     Alex
> 
>     Guillaume Cottenceau schrieb:
> 
>         "Hillel" <hillel 'at' ecommunicate.biz
>         <http://ecommunicate.biz>> writes:
> 
>             Hi,
> 
>             Guillaume I agree it's not so clear from the documentation
>             below, but as far
>             as I know the CTID is the physical position of the row
>             inside the heap.
>             Every UPDATE and some VACUUM operations can affect it.
> 
>             Even if the CTID may be stable over a DELETE as of today,
>             some future
>             storage engine development (like HOT enhancements) may put
>             an end to that.
>             In general, the CTID is not guaranteed to remain the same
>             unless you hold a
>             FOR UPDATE lock on the row.
> 
> 
>         True, though the net result is really similar to the previous one
>         with OIDs. I guess it boils down to knowing why OID why chosen
>         over a proper SERIAL column in the first place, and I don't know
>         the reason for that (I could find no relevant information in the
>         mailing-list archive; though, I guess the reasoning was to have a
>         unique way of creating the kannel DLR table, not one per database
>         engine; however, on that question, the approach proved its limit,
>         IMHO). If OID was fine, I think CTID is fine, since it has a
>         similar behaviour (and I don't think concurrent UPDATEs on the
>         dlr table is a supported usage pattern). If we want to be safe,
>         and we can afford a different way of creating tables per database
>         engine (which is already the case btw, due to the INT(10)
>         difference) then of course, using a proper SERIAL column is the
>         best decision.
> 
> 
> 
> 
> 
> 
> -- 
> Enver