Postgresql 8.4 периодически зависает при доступе к JDBC

У меня очень интенсивное приложение для работы с базами данных, которое работает в течение многих часов и использует несколько потоков, все они общаются с Postgresql через JDBC. Симптомом, который я наблюдаю, является то, что время от времени (от одного до трех раз за каждый "прогон") я получаю одно или несколько застрявших JDBC-соединений, которые, похоже, ждут ответа от базы данных, но, похоже, ждут вечно. Дамп потоков выглядит следующим образом:

"Thread-4367355" daemon prio=6 tid=0x04920c00 nid=0x1e88 runnable [0x04bef000]
   java.lang.Thread.State: RUNNABLE
    at java.net.SocketInputStream.socketRead0(Native Method)
    at java.net.SocketInputStream.read(SocketInputStream.java:129)
    at org.postgresql.core.VisibleBufferedInputStream.readMore(VisibleBufferedInputStream.java:135)
    at org.postgresql.core.VisibleBufferedInputStream.ensureBytes(VisibleBufferedInputStream.java:104)
    at org.postgresql.core.VisibleBufferedInputStream.read(VisibleBufferedInputStream.java:73)
    at org.postgresql.core.PGStream.ReceiveChar(PGStream.java:255)
    at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1165)
    at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:191)
    - locked <0x2c023e10> (a org.postgresql.core.v3.QueryExecutorImpl)
    at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:452)
    at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:337)
    at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:329)

Я бы подумал о какой-то проблеме с блокировкой, если бы не тот факт, что во многих случаях застревает только ОДИН поток. По крайней мере, один из запросов, которые я видел в таком состоянии, был REINDEX, поэтому возможно, что запрос занимает достаточно много времени. В надежде найти решение, я обновил драйвер JDBC с 8.4 до 9.1, но проблема все еще возникает. В журналах Postgresql также нет ничего необычного. Есть идеи по дальнейшей диагностике (кроме использования pg_locks)?