How to diagnose application "hangs" in pg_receive? - Mailing list pgsql-jdbc

From Clemens Eisserer
Subject How to diagnose application "hangs" in pg_receive?
Date
Msg-id BANLkTin_F0DVziRuw7jWn+CAB7PYKZLHew@mail.gmail.com
Whole thread Raw
Responses Re: How to diagnose application "hangs" in pg_receive?  (Hannu Krosing <hannu@2ndQuadrant.com>)
Re: How to diagnose application "hangs" in pg_receive?  (Maciek Sakrejda <msakrejda@truviso.com>)
List pgsql-jdbc
Hi,

A hibernate based application I wrote suffers from "hangs" - the
thread which should fetch the data is stuck at pg_receive (the
function reading back data from the socket).
My first idea were threading errors, however after careful code review
I couldn't find suspicious code.
The application doesn't do any explicit locking, an excerpt of the
locking table is at the end of the email.

Any idea what could be going wrong here?
Except a broken connction, what could be the reason for never arriving
reply from the server?

Thank you in advance, Clemens


   datname   |            relname             |           mode
  | granted | usename  |             substr             |
query_start          |       age       | procpid

-------------+--------------------------------+--------------------------+---------+----------+--------------------------------+-------------------------------+-----------------+---------
 khbldb_prod | startkladde_pkey               | RowExclusiveLock
  | t       | postgres | autovacuum: VACUUM public.star | 2011-05-21
11:19:51.780587+01 | 03:43:21.367065 |   18241
 khbldb_prod | startkladde                    |
ShareUpdateExclusiveLock | t       | postgres | autovacuum: VACUUM
public.star | 2011-05-21 11:19:51.780587+01 | 03:43:21.367065 |
18241
 khbldb_prod | kladde_flugnr_index            | RowExclusiveLock
  | t       | postgres | autovacuum: VACUUM public.star | 2011-05-21
11:19:51.780587+01 | 03:43:21.367065 |   18241
 khbldb_prod | kladde_schleppid_index         | RowExclusiveLock
  | t       | postgres | autovacuum: VACUUM public.star | 2011-05-21
11:19:51.780587+01 | 03:43:21.367065 |   18241
 khbldb_prod | kladde_lehrer_index            | RowExclusiveLock
  | t       | postgres | autovacuum: VACUUM public.star | 2011-05-21
11:19:51.780587+01 | 03:43:21.367065 |   18241
 khbldb_prod | kladde_nachplatzid_index       | RowExclusiveLock
  | t       | postgres | autovacuum: VACUUM public.star | 2011-05-21
11:19:51.780587+01 | 03:43:21.367065 |   18241
 khbldb_prod | kladde_bmok_index              | RowExclusiveLock
  | t       | postgres | autovacuum: VACUUM public.star | 2011-05-21
11:19:51.780587+01 | 03:43:21.367065 |   18241
 khbldb_prod | kladde_vonplatzid_index        | RowExclusiveLock
  | t       | postgres | autovacuum: VACUUM public.star | 2011-05-21
11:19:51.780587+01 | 03:43:21.367065 |   18241
 khbldb_prod |                                | ExclusiveLock
  | t       | postgres | autovacuum: VACUUM public.star | 2011-05-21
11:19:51.780587+01 | 03:43:21.367065 |   18241
 khbldb_prod | kladde_datum_index             | RowExclusiveLock
  | t       | postgres | autovacuum: VACUUM public.star | 2011-05-21
11:19:51.780587+01 | 03:43:21.367065 |   18241
 khbldb_prod | statusindex                    | RowExclusiveLock
  | t       | postgres | autovacuum: VACUUM public.star | 2011-05-21
11:19:51.780587+01 | 03:43:21.367065 |   18241
 khbldb_prod | kladde_pilot_index             | RowExclusiveLock
  | t       | postgres | autovacuum: VACUUM public.star | 2011-05-21
11:19:51.780587+01 | 03:43:21.367065 |   18241
 khbldb_prod | bzbisindex                     | RowExclusiveLock
  | t       | postgres | autovacuum: VACUUM public.star | 2011-05-21
11:19:51.780587+01 | 03:43:21.367065 |   18241
 khbldb_prod | kladde_flugzeug_index          | RowExclusiveLock
  | t       | postgres | autovacuum: VACUUM public.star | 2011-05-21
11:19:51.780587+01 | 03:43:21.367065 |   18241
 khbldb_prod | kladde_geschlepptid_index      | RowExclusiveLock
  | t       | postgres | autovacuum: VACUUM public.star | 2011-05-21
11:19:51.780587+01 | 03:43:21.367065 |   18241

//No eclusive locks are held by the application:
 khbldb_prod | verkauf_type_index             | AccessShareLock
  | t       | khbl     | <IDLE> in transaction          | 2011-05-21
13:04:53.930505+01 | 01:58:19.217147 |   18637
 khbldb_prod | rechnungsstatus_pkey           | AccessShareLock
  | t       | khbl     | <IDLE> in transaction          | 2011-05-21
13:04:53.930505+01 | 01:58:19.217147 |   18637
 khbldb_prod | bzbisindex                     | AccessShareLock
  | t       | khbl     | <IDLE> in transaction          | 2011-05-21
13:04:53.930505+01 | 01:58:19.217147 |   18637
 khbldb_prod | rechnungsstatus                | AccessShareLock
  | t       | khbl     | <IDLE> in transaction          | 2011-05-21
13:04:53.930505+01 | 01:58:19.217147 |   18637
 khbldb_prod | kladde_lehrer_index            | AccessShareLock
  | t       | khbl     | <IDLE> in transaction          | 2011-05-21
13:04:53.930505+01 | 01:58:19.217147 |   18637

pgsql-jdbc by date:

Previous
From: Israel Ben Guilherme Fonseca
Date:
Subject: Re: Incoming/Sent traffic data
Next
From: Hannu Krosing
Date:
Subject: Re: How to diagnose application "hangs" in pg_receive?