Re: Surviving transaction-ID wraparound, take 2

From: Horst Herb <hherb(at)malleenet(dot)net(dot)au>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Surviving transaction-ID wraparound, take 2
Date: 2001-08-14 01:03:30
Message-ID: 0108141103300Q.01835@munin.gnumed.dhs.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 who need to establish a true long term audit trail?
For us, still the most elegant solution would be a quasi unlimited supply of
unique row identifiers. 64 bit would be a huge help (and will be ubiquitous
in a few years time anyway).

Everything else will have far greater performance impact for us. While it
might not suit everybody, I can't see why it should be a problem to offer
this as an *option*

There are other applications where we need database wide unique row
identifiers; in our project for example we allow row level encryption on
non-indexed attributes across alll tables. How would you implement such a
thing without having unique row identifiers across your whole database? You
would need to reference both to row AND table, and that must certainly be
more expensive in terms of performance.

Horst

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2001-08-14 01:35:05 Re: Surviving transaction-ID wraparound, take 2
Previous Message Tatsuo Ishii 2001-08-14 01:02:41 Re: Vague idea for allowing per-column locale