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

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

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

Here is the background on this email (and other like it). My corporate
office changed my email address 4 times in a 3 week period (company mergers
and such). In order to send mail, I was forced to subscribe to each list
using my new email addresses. I then had three email addresses registered
to each list. The corporate office then changed my email address again
because another individual in the company was assigned my current email
address. Apparently he had been with the company longer. Now I am getting
two copies of every email and he gets a copy of every email. I had been
trying for weeks to unsubscribe the extra emails from the lists but either
the unsubscribe was not supported, would fail, or just would not work. I
finally emailed the owner of the lists and he has corrected the problem.
The individual getting these messages apparently had enough of these email
and started returning them back to the sender. Sorry for the inconvenience.
It should not happen again. I don't think this was an intended spam.

Thanks, Michael

-----Original Message-----
From: The Hermit Hacker [SMTP:scrappy@hub.org]
Sent: Thursday, May 06, 1999 8:40 AM
To: Michael Davis
Cc: Hiroshi Inoue; Vadim Mikheev; Postgresql Developers List
Subject: 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