Re: [HACKERS] Savepoints...
От | Vadim Mikheev |
---|---|
Тема | Re: [HACKERS] Savepoints... |
Дата | |
Msg-id | 376889CD.C875A2F2@krs.ru обсуждение исходный текст |
Ответ на | RE: [HACKERS] Savepoints... ("Hiroshi Inoue" <Inoue@tpf.co.jp>) |
Список | pgsql-hackers |
Hiroshi Inoue wrote: > > > > > We'll remember command id for the first "update t" only > > (i.e. for the first ROW EXCLUSIVE mode lock over table t). > > > > How to reduce lock counter for ROW EXCLUSIVE mode lock > over table t? No reasons to do it for ROW EXCLUSIVE mode lock (backend releases such locks only when commit/rollback[to savepoint]), but we have to do it in some other cases - when we explicitly release acquired locks after scan/statement is done. And so, you're right: in these cases we have to track lock acquisitions. Well, we'll add new arg to LockAcquire (and other funcs; we have to do it anyway to implement NO WAIT, WAIT XXX secs locks) to flag lmgr that if the lock counter is not 0 (for 0s - i.e. first lock acquisition - command id will be remembered by lmgr anyway) than this counter must be preserved in implicit savepoint. In the case of abort lock counters will be restored. Space allocated in implicit savepoint will released. All the above will work till there is no UNLOCK statement. Thanks! > > And more questions. > > HEAP_MARKED_FOR_UPDATE state could be rollbacked ? Yes. FOR UPDATE changes t_xmax and t_cmax. Vadim
В списке pgsql-hackers по дате отправления: