Savepoints...
От | Vadim Mikheev |
---|---|
Тема | Savepoints... |
Дата | |
Msg-id | 3767A2CF.E6E4A5F9@krs.ru обсуждение исходный текст |
Ответы |
Re: [HACKERS] Savepoints...
RE: [HACKERS] Savepoints... |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: