MVCC works in serialized mode!

CVS is just updated...

Please try concurrent writes/reads...

It'll take some time to implement READ COMMITTED mode...

Note:

1. Vacuum is not updated yet and so will remove deleted tuples
   though some xactions would like to see them in selects...

2. LOCK TABLE modes are not yet implemented...

3. As well as SELECT ... FOR UPDATE: I need in advice here!

   Do Oracle, Informix etc support SELECT FOR UPDATE if
   there are aggregates, group by, distinct in SELECT ???
   Is SELECT FOR UPDATE allowed in subqueries ???

4. Rtree & gist indices use _relation level_ locking -
   no wish, no time to change them...
   Executor locks them in exclusive mode (on relation level)
   for update/insert and so prevents deadlocks...
   These locks released after _query_ is done - not so bad
   for concurrency...

5. Hash & btree indices use _page level_ locking and so
   are "opened" for deadlocks -:))
   (In the case of concurrent inserts/updates when
    indices are used for scans).
   
   I hope to change btree - it's possible, -
   but not hashes...

6. I'm not happy with current deadlock detection code!
   It seems that backend does DeadLockCheck each time
   when timer expired - shouldn't this be done _once_,
   before backend is going to sleep ?!

7. As I read in Sybase documentation the default 
   standard transaction mode is _chained_ - all
   queries before explicit COMMIT/ABORT are run in _single
   transaction_... But we have to use BEGIN/END to get it!
   This was not so bad for system with relation level locks,
   but now only the same row writes block one other and so
   chained mode seems more appropriate...
   
   Shouldn't we change default transaction mode now?
   And use option/SET TRANSACTION MODE to switch to
   un-chained mode if one like it?

Vadim