Thread: troubleshooting "idle in transaction"
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
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 >