To have them I need to add tuple id (6 bytes) to heap tuple
header. Are there objections? Though it's not good to increase
tuple header size, subj is, imho, very nice feature...
Implementation is , hm, "easy":
- heap_insert/heap_delete/heap_replace/heap_mark4update will remember updated tid (and current command id) in relation
cacheand store previously updated tid (remembered in relation cache) in additional heap header tid;
- lmgr will remember command id when lock was acquired;
- for a savepoint we will just store command id when the savepoint was setted;
- when going to sleep due to concurrent the-same-row update, backend will store MyProc and tuple id in shmem hash
table.
When rolling back to a savepoint, backend will:
- release locks acquired after savepoint;
- for a relation updated after savepoint, get last updated tid from relation cache, walk through relation, set
HEAP_XMIN_INVALID/HEAP_XMAX_INVALIDin all tuples updated after savepoint and wake up concurrent writers blocked on
thesetuples (using shmem hash table mentioned above).
The last feature (waking up of concurrent writers) is most hard
part to implement. AFAIK, Oracle 7.3 was not able to do it.
Can someone comment is this feature implemented in Oracle 8.X,
other DBMSes?
Now about implicit savepoints. Backend will place them before
user statements execution. In the case of failure, transaction
state will be rolled back to the one before execution of query.
As side-effect, this means that we'll get rid of complaints
about entire transaction abort in the case of mistyping
causing abort due to parser errors...
Comments?
Vadim
