Check the pg_locks system view in the pg_catalog schema. It will tell
you a wealth of information.
Peter
Dan Harris wrote:
Greetings..
I'm running 8.0.12 and the system has been very stable for years now
with no significant application changes. I am using
Apache::Session::Postgres in a web application to store session
state. This has really been flawless for us so far, but lately I've
caught a few occurrences where I will see in GNU top, the following:
9136 postgres 16 0 546m 9.8m 8080 S 0 0.0 0:00.00 1
postgres: postgres sessions harvard(49197) idle in transaction
10892 postgres 16 0 546m 9180 7356 S 0 0.0 0:00.01 3
postgres: postgres sessions harvard(49649) SELECT waiting
12174 postgres 16 0 546m 9172 7348 S 0 0.0 0:00.00 3
postgres: postgres sessions harvard(51158) SELECT waiting
12175 postgres 16 0 546m 9152 7328 S 0 0.0 0:00.01 1
postgres: postgres sessions harvard(51159) SELECT waiting
12176 postgres 16 0 546m 9112 7288 S 0 0.0 0:00.01 1
postgres: postgres sessions harvard(51160) SELECT waiting
I can connect to the database fine and select from it when this
occurs, but I'm guessing that the owner of that particular session row
is refreshing their browser and seeing it 'hang', causing the lock
jam. I know this could potentially be a problem with Apache::Session
logic, but that module has not been updated for as long as I can
remember, so I'm wondering if this could be a database issue somehow?
Previously, I have just killed the process that's idle in transaction,
then things clean up.. However, this doesn't feel very clean.
Can anyone recommend a good process for learning why exactly that
transaction is not completing? Or, is there a postgresql.conf setting
that can automatically kill these errant locks?
-Dan
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
