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

[catmat]

Karsten Hilbert wrote:

> > 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.
>
>  
at least they could say "tsk, tsk, this comes up every x months or so; 
please see ... <href>"
which is both patronizing , yet politer ;)

Maybe the whole thing is just an embarassment for the transactional 
database designer.

> > 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.
>
>  
what I get is the ability to read committed updates of other transactions,
when I set ... serializable ; 
this makes it no different from set trans. isolation read committed , or 
what am I missing?

> > 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
>  
not when permissions are set ;)

actually, what I don't like is how unportable using xmin seems ,
what if someone wanted to use maxdb or firebird instead?