From: | Hannu Krosing <hannu(at)skype(dot)net> |
---|---|
To: | Darcy Buskermolen <darcyb(at)commandprompt(dot)com> |
Cc: | pgsql-patches(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, Marko Kreen <markokr(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Jan Wieck <JanWieck(at)yahoo(dot)com> |
Subject: | Re: [HACKERS] [PATCH] Provide 8-byte transaction IDs to |
Date: | 2006-07-26 21:01:15 |
Message-ID: | 1153947675.2928.12.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Ü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(at)momjian(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2006-07-26 21:02:38 | Re: [HACKERS] Resurrecting per-page cleaner for btree |
Previous Message | Tom Lane | 2006-07-26 20:58:44 | Re: extension for sql update |
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2006-07-26 21:02:38 | Re: [HACKERS] Resurrecting per-page cleaner for btree |
Previous Message | Tom Lane | 2006-07-26 20:58:44 | Re: extension for sql update |