Re: Revised Patch to allow multiple table locks in "Unison"
От | Neil Padgett |
---|---|
Тема | Re: Revised Patch to allow multiple table locks in "Unison" |
Дата | |
Msg-id | 3B61B4A9.9AD60EE3@redhat.com обсуждение исходный текст |
Ответ на | Revised Patch to allow multiple table locks in "Unison" (Neil Padgett <npadgett@redhat.com>) |
Ответы |
Re: Revised Patch to allow multiple table locks in "Unison"
Re: Revised Patch to allow multiple table locks in "Unison" |
Список | pgsql-patches |
Bruce Momjian wrote: > > The problem with this patch is that it doesn't always lock the tables in > the order supplied by the user, leading to possible deadlock. My guess > is that you need to try locking A, B, C and if B hangs, I think you need > to sleep on B, and when you get it, release the lock on B and try A, B, > C again. I know this is a pain and could fail multiple times, but I > think we have to do it this ay. > Deadlocks are not possible with this patch. The four conditions needed for deadlock are (according to Operating Systems: Internals and Design Principles, 4th Ed. by W. Stallings): 1. Mutual exclusion: Only one process may use a resource at a time. 2. Hold and wait: A process may hold allocated resources while awaiting assignment of others. 3. No preemption: No resources can be forcibly removed from a process holding it. 4. Circular wait: A closed chain of processes exists, such that each process holds at least one resource needed by the next process in the chain. For deadlock prevention one needs only to prevent the existence of at least one of the four conditions. The patch code never holds any of requested locks, while waiting for a locked relation to become free. If a lock on all tables in the lock list cannot be acquired at once, it backs off and releases all locks. Stallings writes about preventing condition 3: "This condition can be prevented in several ways. [. . .] [One way is to require that,] if a process holding certain resources is denied a further request, that process must release its original resources and, if necessary, request them again together with the additional resources." This is exactly what the patch does. Observe that if one lock is not available, the patch releases all locks so far acquired, and then acquires the locks again. Hence, condition 3 is prevented, and so deadlock is prevented. Neil p.s. Is this mailing list always this slow? -- Neil Padgett Red Hat Canada Ltd. E-Mail: npadgett@redhat.com 2323 Yonge Street, Suite #300, Toronto, ON M4P 2C9
В списке pgsql-patches по дате отправления: