| 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 |
| Subject: | Re: some question about deadlock |
| Date: | 2006-05-29 15:51:38 |
| Message-ID: | 14600.1148917898@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2006-05-29 16:01:09 | Re: question about security hole CVE-2006-2313 and UTF-8 |
| Previous Message | Bruce Momjian | 2006-05-29 15:43:29 | Re: some question about deadlock |