Re: [HACKERS] MVCC works in serialized mode!

Hiroshi Inoue wrote:
> 
> I have a question about new default(isolation level / transaction mode).
> 
> How do we upgrade existent programs,if default is different
> from current ?
> I think the isolation level of current PostgreSQL is SERIALIZABLE
> and the transaction mode is un-chained..
> 
> As to the isolation level,even SERIALIZABLE isolaton level can't guarantee
> the integrity of current level.
> So we must change existent programs anyway ?

You're right!
The word from Oracle: (-:))

"Because Oracle does not use read locks, even in serializable 
transactions, data read by one transaction can be overwritten 
by another. Transactions that perform database consistency
checks at the application level should not assume that the data 
they read will not change during the execution of the transaction 
(even though such changes are not visible to the transaction). 
Database inconsistencies can result unless such application-level 
consistency checks are coded with this in mind, even when using 
serializable transactions.
...
Although Oracle serializable mode is compatible with SQL92 and 
offers many benefits as compared with read-locking implementations, 
it does not provide semantics identical to such systems. 
Application designers must take into account the fact that reads 
in Oracle do not block writes as they do in other systems. 
Transactions that check for database consistency at the application 
level may require coding techniques such as the use of
SELECT FOR UPDATE. This issue should be considered when                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
applications using serializable mode are ported to Oracle 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
from other environments."
^^^^^^^^^^^^^^^^^^^^^^^

1. All our applications run in serializable mode now.
2. "Environment" is changed from locking to  multi-versioning.

This has to be explained in release notes.

Should we implement ability to run backend in mode compatible
with old versions (it seems easy to do - just use AccessExclusive 
Lock for UPDATE/INSERT/DELETE in Executor and don't release
AccessShare Lock in heap_endscan) ?

Vadim