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
