Re: [PATCHES] [PATCH] Provide 8-byte transaction IDs to - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: [PATCHES] [PATCH] Provide 8-byte transaction IDs to
Date
Msg-id 1153947675.2928.12.camel@localhost.localdomain
Whole thread Raw
In response to Re: [PATCHES] [PATCH] Provide 8-byte transaction IDs to user level  (Darcy Buskermolen <darcyb@commandprompt.com>)
List pgsql-hackers
Ühel kenal päeval, K, 2006-07-26 kell 13:41, kirjutas Darcy Buskermolen:
> On Wednesday 26 July 2006 13:04, Tom Lane wrote:
> > Bruce Momjian <bruce@momjian.us> writes:
> > > I am sure you worked hard on this, but I don't see the use case, nor
> > > have I heard people in the community requesting such functionality.
> > > Perhaps pgfoundry would be a better place for this.
> >
> > The part of this that would actually be useful to put in core is
> > maintaining a 64-bit XID counter, ie, keep an additional counter that
> > bumps every time XID wraps around.  This cannot be done very well from
> > outside core but it would be nearly trivial, and nearly free, to add
> > inside.  Everything else in the patch could be done just as well as an
> > extension datatype.
> >
> > (I wouldn't do it like this though --- TransactionIdAdvance itself is
> > the place to bump the secondary counter.)
> >
> > The question though is if we did that, would Slony actually use it?

It seems that Slony people still hope to circumvent the known brokenness
of xxid btree indexes by dropping and creating them often enough and/or
trying other workarounds.

> If it made sence to do it, then yes we would do it. The problem ends up being
> Slony is designed to work across a multitude of versions of PG, and unless
> this was backported to at least 7.4, it would take a while (ie when we
> stopped supporting versions older than it was ported into)  before we would
> make use of it.

We already have an external implementation, which requires a function
call to be executed at an interval of a few hundreds of millions
transactions to pump up the higher int4 when needed.

It would probably be easy to backport it to any version of postgres
which is supported by slony.

Being in core just makes the overflow accounting part more robust.

The function to retrieve the 8-byte trx id will look exatly the same
from userland in both cases.

> >
> >             regards, tom lane
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 2: Don't 'kill -9' the postmaster
>
--
----------------
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia

Skype me:  callto:hkrosing
Get Skype for free:  http://www.skype.com


pgsql-hackers by date:

Previous
From: "Sailesh Krishnamurthy"
Date:
Subject: Update on TelegraphCQ
Next
From: Hannu Krosing
Date:
Subject: Re: [PATCHES] [PATCH] Provide 8-byte transaction IDs to