Re: XMIN semantic at peril ?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: XMIN semantic at peril ?
Дата
Msg-id 13499.1192113857@sss.pgh.pa.us
обсуждение исходный текст
Ответ на XMIN semantic at peril ?  (Karsten Hilbert <Karsten.Hilbert@gmx.net>)
Ответы Re: XMIN semantic at peril ?
Re: XMIN semantic at peril ?
Re: XMIN semantic at peril ?
Список pgsql-general
Karsten Hilbert <Karsten.Hilbert@gmx.net> writes:
>   How likely is XMIN (or equivalent) to become invisible to
>   SQL level user space ?

No one has suggested this.  I suppose the argument could be made that
the system columns are an unwarranted intrusion on users' column
namespace, but we'd probably handle that by demoting them to
second-class citizens, not hiding them entirely --- there are far too
many apps that rely on ctid, for instance, and I think some that are
doing like you do with xmin.  So as long as you don't create a user
column named xmin in your tables, you could expect to access the system
column.

>   How likely is XMIN (or equivalent) to NOT change on each
>   successful (write) transaction commit anymore ?

No chance of that, unless we abandon MVCC for something else, which
again seems highly unlikely.

One question I'd have though is whether "freezing" of old tuples is
likely to confuse your app.  That process might get more aggressive
in the future (it already is more aggressive in 8.2 than before,
depending on where vacuum_freeze_min_age is set).

The only argument you cited that seems impressive to me is the one
about it being a Postgres-ism.  Are you willing to have GNUmed tied
tightly to Postgres?

            regards, tom lane

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

Предыдущее
От: Stefan Schwarzer
Дата:
Сообщение: Calculation of per Capita on-the-fly - problems with SQL syntax
Следующее
От: Stefan Schwarzer
Дата:
Сообщение: Re: ORDER BY - problem with NULL values