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
