	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





Wed, 5 May 1999 09:19:09 -0500 
Michael Davis <Michael.Davis@tvguide.com>
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 


Thu, 6 May 1999 11:40:22 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
RE: [HACKERS] I'm planning some changes in lmgr...