On Tue, Oct 09, 2007 at 07:18:07AM -0400, Dave Cramer wrote: >>> Yeah, I'd have to agree with that adage. Of course one could argue that >>> XMIN is a premature optimization. >> >> It is not (intended as) an optimization at all but rather a >> mechanism to detect imminent semantic corruption. >> > I view it as optimization since it avoids a column Oh, OK, I wasn't thinking about the diskspace side of things. Under that point of view, yes, it's an optimization, which, however, played no role in the design decision.
>>> as far as postgresql goes the new HOT patch comes dangerously close to >>> changing the semantics of XMIN. >>> > I said dangerously close. It doesn't change the semantics but postgresql is > developing faster than it has in the past I know, I know. I do acknowledge that it has potential to become a problem somewhere down the line. >> part of the very root of MVCC tuple visibility rules. The >> only real danger would be if *user* visibiity of that change >> indicator goes away so we cannot use it anymore. This is >> highly unlikely given PGs track record of exposing more >> rather than less state information over the years. > oid's are now gone by default in user tables .... Sure, as I pointed out earlier in this thread. > Use either a version row or a timestamp row As I said: I do know how to solve it technically. And, too, I am open for patches. > and implement optimistic locking > > http://www.agiledata.org/essays/concurrencyControl.html Well, see, that's the difference between a doctor and an IT person: I know what I need and you know what it's called. So, what we do with XMIN is optimistic locking with marking the source with a unique identifier the latter of which comes on the cheap by use of XMIN. We could replace XMIN with a real column which would then require update rules or rather triggers on all affected tables. A missing column on a table would be detected by the business object code (since it fails to read the column). As I said: I am open to patches. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
