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(at)EXCHANGE, PostgreSQL
> Developers List <hackers @ postgreSQL.org>@SMTP(at)EXCHANGE
> cc:
> Subject: RE: [HACKERS] I'm planning some changes in lmgr...
>
> > -----Original Message-----
> > From: owner-pgsql-hackers(at)postgreSQL(dot)org
> > [mailto:owner-pgsql-hackers(at)postgreSQL(dot)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(at)tpf(dot)co(dot)jp
>
>
>
>
>

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