Skip site navigation (1) Skip section navigation (2)

Re: some question about deadlock

From: "ipig" <ipig(at)ercist(dot)iscas(dot)ac(dot)cn>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: some question about deadlock
Date: 2006-05-29 16:10:34
Message-ID: 006401c6833a$78374df0$3c1a4dd2@iipig (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
   In your example, it seems that process B is the first such waiter( the request of B conflicts AccessShareLock).
Best regards.

----- Original Message ----- 
From: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "ipig" <ipig(at)ercist(dot)iscas(dot)ac(dot)cn>
Cc: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>; <pgsql-hackers(at)postgresql(dot)org>
Sent: Monday, May 29, 2006 11:51 PM
Subject: Re: [HACKERS] some question about deadlock 

> "ipig" <ipig(at)ercist(dot)iscas(dot)ac(dot)cn> writes:
>>     That is to say, if p0 wants to lock A again, then p0 will be put before p1, and p0 will be at the head of the queue. Why do we need to find the first waiter which conflicts p0? I think that p0 must be added at the head of the wait queue.
> Your analysis is assuming that there are only two kinds of lock, which
> is not so.  Process A might hold a weak lock and process B a slightly
> stronger lock that doesn't conflict with A's.  In the wait queue there
> might be process C wanting a lock that conflicts with B's but not A's,
> followed by process D wanting a strong lock that conflicts with all three.
> Now suppose A wants to get a lock of the same type D wants.  Since this
> conflicts with B's existing lock, A must wait.  A must go into the queue
> before D (else deadlock) but if possible it should go after C, on
> fairness grounds.
> A concrete example here is
> A has AccessShareLock (reader's lock)
> B has RowExclusiveLock (writer's lock)
> C wants ShareLock (hence blocked by B but not A)
> D wants AccessExclusiveLock (must wait for all three)
> If A wants to upgrade to AccessExclusiveLock, it *must* queue in front
> of D, and we'd prefer that it queue behind C not in front of C.
> regards, tom lane
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2006-05-29 16:16:35
Subject: Re: some question about deadlock
Previous:From: Tom LaneDate: 2006-05-29 16:01:09
Subject: Re: question about security hole CVE-2006-2313 and UTF-8

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group