Re: XMIN semantic at peril ?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net>
Cc: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: XMIN semantic at peril ?
Date: 2007-10-11 14:44:17
Message-ID: 13499.1192113857@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Benjamin Arai 2007-10-11 14:52:29 Re: [PERFORM] Slow TSearch2 performance for table with 1 million documents.
Previous Message Stefan Schwarzer 2007-10-11 13:50:09 Calculation of per Capita on-the-fly - problems with SQL syntax