Tom Lane wrote:
> Horst Herb <[EMAIL PROTECTED]> writes:
> > On Tuesday 14 August 2001 02:25, you wrote:
> >> I still think that expanding transaction IDs (XIDs) to 8 bytes is no help.
>
> > But what about all of us who need to establish a true long term audit trail?
> > For us, still the most ele
Horst Herb <[EMAIL PROTECTED]> writes:
> On Tuesday 14 August 2001 02:25, you wrote:
>> I still think that expanding transaction IDs (XIDs) to 8 bytes is no help.
> But what about all of us who need to establish a true long term audit trail?
> For us, still the most elegant solution would be a q
On Tuesday 14 August 2001 02:25, you wrote:
> I still think that expanding transaction IDs (XIDs) to 8 bytes is no help.
> Aside from portability and performance issues, allowing pg_log to grow
> without bound just isn't gonna do. So, the name of the game is to recycle
But what about all of us
> 3. VACUUM will have the responsibility of replacing old normal XIDs with
> FrozenXID. It will do this whenever a committed-good tuple has xmin less
> than a cutoff XID. (There is no need to replace xmax, since if xmax is
> committed good then the tuple itself will be removed.) The cutoff XID
This is an attempt to flesh out the ideas of my earlier proposal
(http://fts.postgresql.org/db/mw/msg.html?mid=67786) into a complete
description of how things should work. It's still largely the same
proposal, but I have adopted a couple of the ideas from the followup
discussion --- notably Vadi
