RE: [HACKERS] I'm planning some changes in lmgr...

Ya know, its almost tempting to send /kernel to ppl that spam lists like
this :(


On Wed, 5 May 1999, Michael Davis wrote:

>     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 PM
>     To:    Vadim Mikheev <vadim @ krs.ru>@SMTP@EXCHANGE, PostgreSQL
> Developers List <hackers @ postgreSQL.org>@SMTP@EXCHANGE
>     cc:     
>     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 Behalf Of Vadim
> Mikheev
>     > Sent: Sunday, May 02, 1999 12:23 AM
>     > To: PostgreSQL Developers List
>     > Subject: [HACKERS] I'm planning some changes in lmgr...
>     > 
>     > 
>     > but have no time to do them today and tomorrow -:(.
>     > 
>     > 1. Add int waitMask to LOCK to speedup checking in
> LockResolveConflicts:
>     >    if lock requested conflicts with lock requested by any waiter 
>     >    (and we haven't any lock on this object) -> sleep
>     > 
>     > 2. Add int holdLock (or use prio) to PROC to let other know
>     >    what locks we hold on object (described by PROC->waitLock)
>     >    while we're waiting for lock of PROC->token type on
>     >    this object.
>     > 
>     >    I assume that holdLock & token will let us properly 
>     >    and efficiently order waiters in LOCK->waitProcs queue
>     >    (if we don't hold any 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 transaction 
>     should 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 such a case.
> 
>     Thanks.
> 
>     Hiroshi Inoue
>     Inoue@tpf.co.jp
> 
> 
> 
> 
> 

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org