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