Group: pgsql.admin


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