tmoore wrote:
> The test is not doing any transaction based work, the write
> functions just do sql insert, no begin commit blocks at the
> application level.
Well something is starting transactions; otherwise you wouldn't have
a transaction sitting "idle in transaction". Are you perhaps
accessing the database through Java with setAutoCommit(false)? (This
is one of many ways you could have a transaction pending.)
Whatever is starting the transactions is connecting through the local
loopback address, since that connection is showing IP address
127.0.0.1. It's connecting to uisdb as the postgres user. Other
connections are not using TCP connections, which is why I suspected
it might be a Java process -- the JDBC driver always uses a TCP
connection.
> Any tips on interpreting pg_locks ?
http://wiki.postgresql.org/wiki/Lock_Monitoring
> No blocking occurred.
I'm not following you. Originally you were saying that there was a
deadlock, which is a set of blocks which form a cycle. You also
said that things were stuck until you killed a particular connection,
at which point things got moving again, which at least suggests the
possibility of blocking. One of the connections you showed reported
that it was waiting, which I think means it is blocked. You showed
one process idle in transaction, and most locks are released at
transaction completion. Why do you say there was no blocking?
-Kevin