Re: ExclusiveLock without a relation in pg_locks

Поиск
Список
Период
Сортировка
От Carlos Oliva
Тема Re: ExclusiveLock without a relation in pg_locks
Дата
Msg-id 200602231608.LAA18948@pbsi.pbsinet.com
обсуждение исходный текст
Ответ на Re: ExclusiveLock without a relation in pg_locks  (Michael Fuhr <mike@fuhr.org>)
Ответы Re: ExclusiveLock without a relation in pg_locks
Список pgsql-general
Thank you very much for your answer.  I think that I am seeing those self
transaction id locks as "ExclusiveLocks"

Would you expect to see an "ExclusiveLock" with a query of type Select (not
Select Update or Update or Insert)?

-----Original Message-----
From: pgsql-general-owner@postgresql.org
[mailto:pgsql-general-owner@postgresql.org] On Behalf Of Michael Fuhr
Sent: Thursday, February 23, 2006 10:05 AM
To: Carlos Oliva
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] ExclusiveLock without a relation in pg_locks

On Thu, Feb 23, 2006 at 08:54:36AM -0500, Carlos Oliva wrote:
> Would connections to a database require crating an extra ExclusiveLock? We
> have some connections to the database that happen to be "idle in
> transaction" and their pids have a granted "Exclusive Lock" in pg_locks.
I
> cannot discern the tables where the ExclusiveLock is being held because
the
> relation field is blank.

http://www.postgresql.org/docs/8.1/interactive/view-pg-locks.html

"Every transaction holds an exclusive lock on its transaction ID
for its entire duration.  If one transaction finds it necessary to
wait specifically for another transaction, it does so by attempting
to acquire share lock on the other transaction ID.  That will succeed
only when the other transaction terminates and releases its locks."

If the relation column is null then you're probably seeing these
transaction ID locks.

> How could I find out the tables that are being locked when I see an
> "ExclusiveLock" in pg_locks.

An easy way to convert a relation's oid to its name is to cast it
to regclass:

SELECT relation::regclass AS relname, * FROM pg_locks;

--
Michael Fuhr

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to majordomo@postgresql.org so that your
       message can get through to the mailing list cleanly



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

Предыдущее
От: Vivek Khera
Дата:
Сообщение: Re: upgrade PostgreSQL 8.x on production FreeBSD
Следующее
От: "Carlos Oliva"
Дата:
Сообщение: Re: ExclusiveLock without a relation in pg_locks