Re: RFC: listing lock status

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: nconway(at)klamath(dot)dyndns(dot)org (Neil Conway)
Cc: Joe Conway <mail(at)joeconway(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RFC: listing lock status
Date: 2002-07-19 03:30:46
Message-ID: 9676.1027049446@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

nconway(at)klamath(dot)dyndns(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-07-19 03:33:21 Re: preventing encoding conversion while starting up
Previous Message Tom Lane 2002-07-19 03:08:42 Re: RFC: listing lock status