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
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 |