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
