Subject: How would I "close" a atble?
From: tgl@sss.pgh.pa.us (Tom Lane)
Date: 12/17/2007 7:11:50 PM
"Tena Sakai" <tsakai@gallo.ucsf.edu> writes:
> I have a weired situation. Out of 17 tables which
> comprise a database, one of them refuses to talk to
> me. When I issue:
> select * from marker;
> it hangs.
Some other session holding an exclusive lock on the table, perhaps?
Have you looked into pg_locks for matches to that table?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Subject: How would I "close" a atble?
From: tgl@sss.pgh.pa.us (Tom Lane)
Date: 12/17/2007 11:25:33 PM
"Tena Sakai" <tsakai@gallo.ucsf.edu> writes:
> That pid 6697 caught my interest and I fished it out of "ps -ef":
> postgres 6697 4916 0 Dec15 ? 00:19:45 postgres: postgres canon [local] REINDEX waiting
> (and for the sake of completeness...)
> postgres 12930 4916 0 11:24 ? 00:00:00 postgres: gbrush canon 172.16.1.106(37819) SELECT waiting
> postgres 18177 4916 0 Dec15 ? 00:00:02 postgres: gbrush canon 172.16.1.106(53874) SELECT waiting
> postgres 18825 4916 0 12:55 ? 00:00:00 postgres: tsakai canon 127.0.0.1(44558) SELECT waiting
The deal here is that the REINDEX is blocked trying to get exclusive
lock on table 16496, while those other guys are (apparently) stacked
up behind it. What you have not shown us is what transaction has
actually *got* a lock on 16496.
> I could kill this process from unix
> level, but before I do so, would you please comment as to why
> this might have happened and what repercussion might I have
> from killing it, if any?
kill -INT would probably be safe enough, but you should first look into
what is blocking the REINDEX from going through.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
Subject: How would I "close" a atble?
From: tgl@sss.pgh.pa.us (Tom Lane)
Date: 12/18/2007 1:43:33 AM
"Tena Sakai" <tsakai@gallo.ucsf.edu> writes:
>> What you have not shown us is what transaction has
>> actually *got* a lock on 16496.
> Would you mind enlightening me as to how I can do so?
Are there no other rows in pg_locks that reference relation 16496?
None of the ones you showed us had granted=t, but there must be one
unless things are much more broken than I think.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
|