Re: XMIN semantic at peril ? - Mailing list pgsql-general

From Tom Lane
Subject Re: XMIN semantic at peril ?
Date
Msg-id 13499.1192113857@sss.pgh.pa.us
Whole thread Raw
In response to XMIN semantic at peril ?  (Karsten Hilbert <Karsten.Hilbert@gmx.net>)
Responses Re: XMIN semantic at peril ?  (Karsten Hilbert <Karsten.Hilbert@gmx.net>)
Re: XMIN semantic at peril ?  ("Filip Rembiałkowski" <plk.zuber@gmail.com>)
Re: XMIN semantic at peril ?  (Karsten Hilbert <Karsten.Hilbert@gmx.net>)
List 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 by date:

Previous
From: Stefan Schwarzer
Date:
Subject: Calculation of per Capita on-the-fly - problems with SQL syntax
Next
From: Stefan Schwarzer
Date:
Subject: Re: ORDER BY - problem with NULL values