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
SELECTFOR UPDATE allowed in subqueries ???
 

4. Rtree & gist indices use _relation level_ locking -  no wish, no time to change them...  Executor locks them in
exclusivemode (on relation level)  for update/insert and so prevents deadlocks...  These locks released after _query_
isdone - 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/updateswhen   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
explicitCOMMIT/ABORT are run in _single  transaction_... But we have to use BEGIN/END to get it!  This was not so bad
forsystem 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-chainedmode if one like it?
 

Vadim