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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
