Hi, 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" <[EMAIL PROTECTED]> To: "ipig" <[EMAIL PROTECTED]> Cc: "Bruce Momjian" <pgman@candle.pha.pa.us>; <pgsql-hackers@postgresql.org> Sent: Monday, May 29, 2006 11:51 PM Subject: Re: [HACKERS] some question about deadlock > "ipig" <[EMAIL PROTECTED]> 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? > > http://archives.postgresql.org ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
