Re: Surviving transaction-ID wraparound, take 2

Поиск
Список
Период
Сортировка
От Horst Herb
Тема Re: Surviving transaction-ID wraparound, take 2
Дата
Msg-id 0108141103300Q.01835@munin.gnumed.dhs.org
обсуждение исходный текст
Ответ на Surviving transaction-ID wraparound, take 2  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Surviving transaction-ID wraparound, take 2  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Paul Ramsey
Дата:
Сообщение: Re: PostGIS spatial extensions
Следующее
От: Tatsuo Ishii
Дата:
Сообщение: Re: Vague idea for allowing per-column locale