Re: [HACKERS] [PATCH] Provide 8-byte transaction IDs to

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

In response to

Browse pgsql-hackers by date

  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

Browse pgsql-patches by date

  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