Search Postgresql Archives

XMIN semantic at peril ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux