Re: Revised Patch to allow multiple table locks in "Unison"
От | Bruce Momjian |
---|---|
Тема | Re: Revised Patch to allow multiple table locks in "Unison" |
Дата | |
Msg-id | 200108020145.f721jF000931@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Revised Patch to allow multiple table locks in "Unison" (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Revised Patch to allow multiple table locks in "Unison"
|
Список | pgsql-patches |
> > This is interesting. I'd like to hear what other people think about > > this. > > I doubt that this works --- it still has the same fundamental problem: > that you're not telling the lock manager what it needs to know to > fulfill its responsibility of detecting deadlock. I believe I can still > produce a ping-pong undetected deadlock example with the above behavior; > it'd just take a few more processes. The issue is that you are > expecting the lock manager to detect or not detect deadlock, when you > still have some lock requests up your sleeve that it's not seen yet. > As long as you can block before presenting them all, it can never work. I know there has been talk about having this done in the lock manager, and I know it isn't worth the effort, but I am wondering how you would do it even if you were doing in the lock manager with more information available. You could query all the locks at once but we really can already do that now. We could detect deadlock better. Would that be the only advantage? Seems this whole idea maybe wasn't a good one. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
В списке pgsql-patches по дате отправления: