Your e-mail did not arrive at its intended destination. You need to
send it to Michael J. Davis, not Michael Davis.
From: Hiroshi Inoue <Inoue @ tpf.co.jp> on 05/04/99 10:17 PMTo: Vadim Mikheev <vadim @ krs.ru>@SMTP@EXCHANGE,
PostgreSQL
Developers List <hackers @ postgreSQL.org>@SMTP@EXCHANGEcc: Subject: RE: [HACKERS] I'm planning some changes in
lmgr...
> -----Original Message-----> From: owner-pgsql-hackers@postgreSQL.org> [mailto:owner-pgsql-hackers@postgreSQL.org]On
BehalfOf Vadim
Mikheev> Sent: Sunday, May 02, 1999 12:23 AM> To: PostgreSQL Developers List> Subject: [HACKERS] I'm planning some
changesin lmgr...> > > but have no time to do them today and tomorrow -:(.> > 1. Add int waitMask to LOCK to speedup
checkingin
LockResolveConflicts:> if lock requested conflicts with lock requested by any waiter > (and we haven't any lock
onthis object) -> sleep> > 2. Add int holdLock (or use prio) to PROC to let other know> what locks we hold on object
(describedby PROC->waitLock)> while we're waiting for lock of PROC->token type on> this object.> > I assume
thatholdLock & token will let us properly > and efficiently order waiters in LOCK->waitProcs queue> (if we don't
holdany lock on object -> go after> all waiters with holdLock > 0, etc etc etc).> > Comments?>
First, I agree to check conflicts for ( total - own ) hodling lock
of the target object if transaction has already hold some lock on the object and when some conflicts are detected,the
transactionshould be queued with higher priority than transactions which hold no lock on the object.
Secondly, if a transaction holds no lock on the object, we should check conflicts for ( holding + waiting ) lock of the
object.
And I have a question as to the priority of queueing.Does the current definition of priority mean the urgency of lock
?
It may prevent lock escalation in some cases.But is it effective to avoid deadlocks ? It's difficult for me to find
sucha case.
Thanks.
Hiroshi InoueInoue@tpf.co.jp
