XMIN semantic at peril ?

Hi all,

we use XMIN in our application (http://wiki.gnumed.de) as a
lightweight database-provided "data-changed" marker in a
cross-transaction optimistic locking scheme. The one
characteristic of XMIN we rely on in this scheme is that
"XMIN changes when a (writing) transaction commits
successfully". We don't care *how* it changes, just *that*
it does so.

Now, one kind soul has reviewed our model and suggested that
we really shouldn't rely on XMIN at the end of the day for
various fairly good reasons:

- XMIN is an implementation detail of PostgreSQL (similar to row OIDs)
- GNUmed shouldn't rely on PostgreSQL implementation details

I argued that

- GNUmed only relies on a very general assumption about XMIN behaviour
- PG is likely to always need a way to mark tuples committed one
way or another as that is part of tuple visibility (it needn't be
or be named XMIN, though)
- PG is unlikely (given its track record) of obscuring
visibility of that commit marker

Surely, good counter-arguments were brought forth:

- row OIDs did disappear (or, rather, were defaulted to off)
- it is uncertain whether tuple visibility semantics of PG
will in the future continue to lend themselves to our
cross-tx collision detection/optimistic locking scheme
- particularly in the light of 8.3 HOT patches
- more so in the light of the "Skytools extended transaction ID module"

Of course, we do know how to alleviate the situation
technically by just defining our own marker column and
adding appropriate triggers to the relevant tables to update
said marker. Which, in a perfect world of unlimited
resources, we'd just go ahead and do. In the real world,
however, I'd like to assess the likelihood of our need to
embark on such a mission. So, eventually, in the near- to
mid-future:

How likely is XMIN (or equivalent) to become invisible to
SQL level user space ?

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

Thanks for any insight,
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346