Re: RFC: listing lock status

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: RFC: listing lock status
Дата
Msg-id 9676.1027049446@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: RFC: listing lock status  (nconway@klamath.dyndns.org (Neil Conway))
Ответы Re: RFC: listing lock status  (nconway@klamath.dyndns.org (Neil Conway))
Список pgsql-hackers
nconway@klamath.dyndns.org (Neil Conway) writes:
> On Thu, Jul 18, 2002 at 03:12:53PM -0700, Joe Conway wrote:
>> Maybe the function should take a boolean parameter to indicate whether
>> or not to show locks on objects in pg_* schema?

> I had thought about that, but it occurs to me that the DBA can
> effectively choose this for himself using the relID and databaseID
> returned by the SRF, in combination with pg_database.datlastsysoid.

datlastsysoid is obsolete IMHO --- it was never trustworthy when one
considers the possibility of OID wraparound.

My opinion on this point is (a) pgxactlock locks are special and should
be shown specially --- in the form of "xact a waits for xact b";
(b) locks on other system catalogs are normal locks and should NOT be
discriminated against.  If you have a deadlock condition, the fact that
one of the elements of the lock cycle is on a system catalog isn't going
to magically get you out of the deadlock; nor can you avoid waiting just
because the lock you need is on a system catalog.  Since AFAICS the
only value of a lock status displayer is to investigate problems of one
of those two forms, I can fathom no reason at all that anyone would have
the slightest use for a displayer that arbitrarily omits some locks.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: RFC: listing lock status
Следующее
От: Tom Lane
Дата:
Сообщение: Re: preventing encoding conversion while starting up