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 по дате отправления:

Предыдущее
От: Hiroshi Inoue
Дата:
Сообщение: Re: ODBC Boolean handling
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Patch for Improved Syntax Error Reporting