some question about deadlock

From: "ipig" <ipig(at)ercist(dot)iscas(dot)ac(dot)cn>
To: <pgsql-hackers(at)postgresql(dot)org>
Subject: some question about deadlock
Date: 2006-05-29 11:06:35
Message-ID: 004301c6830f$f4599ee0$8c01a8c0@homepig
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?

Best regards.

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2006-05-29 13:43:43 Re: COPY FROM view
Previous Message Zeugswetter Andreas DCP SD 2006-05-29 09:22:08 Re: Updatable views/with check option parsing