How to debug "could not receive data from client: Connection reset by peer"

I'm running a django-celery application on Ubuntu-12.04.

When I run a celery task from my web interface, I get the following error, taken form postgresql-9.3 logfile (maximum level of log):

2013-11-12 13:57:01 GMT tss_usr 8113 LOG: could not receive data from client: Connection reset by peer 

tss_usr is the postgresql user of the django application database and (in this example) 8113 is the pid of the process who killed the connection, I guess.

Have you got any idea on why this happens or at least how to debug this issue?

To make things work again I need to restart postgresql which is extremely uncomfortable.

3 Answers

I know this is an older post, but I just found it because I had the same error today in my postgres logs. I narrowed it down to a PDO select statement. I'm using Zend Framework 1.10.3 on Ubuntu Precise.

The following pdo statement generated an error if $opinion is a long text string. The column opinion is type Text in my postgres table. The query succeeds if $opinion is under a certain number of characters. 1000 characters works fine. 2000 characters fails with "could not receive data from client: Connection reset by peer".

 $select = $this->db->select() ->from( 'datauserstopics' ) ->where("opinion = ?",trim($opinion)) ->where("datatopicsid = ?",trim($tid)) ->where("datausersid= ?",$datausersid); $stmt = $this->db->query($select); 

I circumvented the problem by using: ->where("substr(opinion,1,100) = ?",trim(substr($opinion,1,100)))

This is not a perfect solution, but for my purposes, the select statement using substr() suffices.

Note that I have no problem inserting long strings into the same table/column. The disconnect problem only appears for me on the PDO select with relatively long text strings.

I'm getting it in 2017 with 9.4, I have no text fields, don't know what a PDO is. My select statement is about 50 bytes long, I'm trying to fetch an int4 and a double precision. I suspect the error message can mean multiple things.

I've since found which indicates it could be a problem with the client configuration. My client is libpg and PQconnectdb() is giving me a CONNECTION_OK return. It works at least partly.

For me, restarting the hypervisor where both the Postgres and the application using it helped. I've seen stack traces in dmesg before, though.