Re: [Gnumed-devel] re: non-serializability detection

[Karsten Hilbert]

> thanks, didn't follow up the original posting.
> 
> >http://archives.postgresql.org/pgsql-general/2004-10/msg01441.php
> 
> wonder why no one responded,  the need to do your own transactioning
> ontop of the postgres transactioning for the class of applications where
> transactions are interactive rather than batch seems an important issue.
And hence has been hashed out elsewhere most likely and those
in the know don't intend to hash it out again and again
whenever some noob stumbles upon it.

> Maybe postgres transactions should have  a non-blocking option which
> returns an exception instead of blocking on concurrent writing.
That comes up every now and then and a NOBLOCK SQL modifier
has been discussed (apparently it exists in Other
Databases(tm)) but hasn't come to fruition in any way.

> ( Can anyone get set transaction isolation level serializable
> to abort a concurrent write, instead of blocking ? Doesn't seem to work on
> my postgres installation.)
Not that I know.

> the auditing function's audit id could also be used, because it's acting as
> an object version id.
True but that depends on our triggers to be there and work
while xmin is handle for us by PostgreSQL and thus more
likely to work properly at all times. Also, the semantics are
just about right because xmin stores the modifying transaction
ID and our initial question is "did another transaction modify
our row ?". Also, people could conceivably fiddle with the
audit id deliberately.

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