Skip site navigation (1) Skip section navigation (2)

long idle connections causing problems?

From: Kaolin Fire <cognosco(at)tentacle(dot)net>
To: pgsql-admin(at)postgresql(dot)org
Subject: long idle connections causing problems?
Date: 2005-08-18 17:00:31
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-admin
Just in the past month or so (no code changes, server changes that I 
know of, etc, for the last six months), I've started getting errors like:

org.postgresql.util.PSQLException: Unknown Response Type 8
	at org.postgresql.core.QueryExecutor.executeV3(
	at org.postgresql.core.QueryExecutor.execute(
	at org.postgresql.core.QueryExecutor.execute(
	at org.postgresql.jdbc1.AbstractJdbc1Statement.execute(
	at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(
	at org.postgresql.jdbc1.AbstractJdbc1Statement.executeQuery(
	at org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(

The particular response type will change each page load.

Doing a process query will show a number of long-running idle postgres 
processes for that particular website.  Other site pools don't seem 
affected, but this one is heavier load than the others (still only ten 
thousand hits a day or so).  If I kill all the idle processes for the 
site, one of them will still remain:

24619 ?        S     14:21 postgres: xxxxxxx xxxxxxx idle

Which I then have to kill -9... which then requires a restart of tomcat 
to hook back up.

possibly relevant version numbers?

    psql (PostgreSQL) 7.4.7
    Apache Tomcat/4.1.31
    Fedora Core 2, kernel 2.6.9

Any  thoughts on what configuration I should be looking at, or if 
there's something I just dearly need to upgrade, ...?

Thank you for your time. :)

-kaolin fire

pgsql-admin by date

Next:From: Lane Van IngenDate: 2005-08-18 17:46:56
Subject: How to Control the Persistence of A PostgreSQL Connection
Previous:From: DarioDate: 2005-08-18 15:45:58
Subject: Re: Server Won't Start On a Copy of Its Own Data Folder

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group