Re: some question about deadlock - Mailing list pgsql-hackers

Hi,   Thanks for your reply.   I changed the format to plain text.
   For the question, suppose that process p0 held the lock of object A, and the wait queue for A is p1,p2,p3,...., that
processp1 is the first waiter in the queue.   Since p1 is in the wait queue, the lock p1 requests must be conflict with
thelock p0 held.    That is to say, if p0 wants to lock A again, then p0 will be put before p1, and p0 will be at the
headof the queue. Why do we need to find the first waiter which conflicts p0? I think that p0 must be added at the head
ofthe wait queue.  For your example, p0 has a read lock and wants an exclusive lock.   Since p0 has a read lock, then
inthe queue, p1 must wait an exclusive lock.  Then p0 will be put before p1, and p0 will be at the head of the queue.
 
 Is there anything I misunderstood?

Best wishes.

----- Original Message ----- 
From: "Bruce Momjian" <pgman@candle.pha.pa.us>
To: "ipig" <ipig@ercist.iscas.ac.cn>
Cc: <pgsql-hackers@postgresql.org>
Sent: Monday, May 29, 2006 9:49 PM
Subject: Re: [HACKERS] some question about deadlock


> ipig wrote:
>> Hi,
>> 
>> Below is the notes from postgresql-8.1.3/src/backend/storage/lmgr/README:
>> 
>> 
>> Lock acquisition (routines LockAcquire and ProcSleep) follows these rules:
>> 
>> 1. A lock request is granted immediately if it does not conflict with
>> any existing or waiting lock request, or if the process already holds an
>> instance of the same lock type (eg, there's no penalty to acquire a read
>> lock twice).  Note that a process never conflicts with itself, eg one
>> can obtain read lock when one already holds exclusive lock.
>> 
>> 2. Otherwise the process joins the lock's wait queue.  Normally it will
>> be added to the end of the queue, but there is an exception: if the
>> process already holds locks on this same lockable object that conflict
>> with the request of any pending waiter, then the process will be
>> inserted in the wait queue just ahead of the first such waiter.  (If we
>> did not make this check, the deadlock detection code would adjust the
>> queue order to resolve the conflict, but it's relatively cheap to make
>> the check in ProcSleep and avoid a deadlock timeout delay in this case.)
>>  Note special case when inserting before the end of the queue: if the
>> process's request does not conflict with any existing lock nor any
>> waiting request before its insertion point, then go ahead and grant the
>> lock without waiting.
>> 
>> 
>> I am confused with that exception(in bold), could some one give me an example?
> 
> Well, first you are requiring people to be reading HTML email to see the
> bold text you added, which is not good:
> 
> an exception: if the process already holds locks on this same lockable
> object that conflict with the request of any pending waiter, then the
> process will be inserted in the wait queue just ahead of the first such
> waiter. 
> 
> An example would be you have a read lock and want an exclusive lock, and
> someone else in the queue is waiting for a read lock too.  In this case,
> the exclusive lock goes before the queued read lock.
> 
> -- 
>  Bruce Momjian   http://candle.pha.pa.us
>  EnterpriseDB    http://www.enterprisedb.com
> 
>  + If your life is a hard drive, Christ can be your backup. +
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings