From: | David Gauthier <davegauthierpg(at)gmail(dot)com> |
---|---|
To: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | "could not receive data from client" && "incomplete startup packet" |
Date: | 2018-02-07 14:34:20 |
Message-ID: | CAMBRECCMdTRQauZhk7sdyO=fO4=RC43rt7rCuf=XKck9OL43vg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi:
I'm experiencing what appears to be an intermittent db connection problem
of some sort (although I may be wrong about that). I have a v9.3.0 PG DB
on a linux box as the DB server. The client is a virtual machine (also
linux) running the same version...
*server side:*
sqf=# select version();
version
-----------------------------------------------------------------------------------
PostgreSQL 9.3.0 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.8.1,
64-bit
(1 row)
*client side:*
sqf=> select version();
version
-----------------------------------------------------------------------------------
PostgreSQL 9.3.0 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.8.1,
64-bit
(1 row)
My app is a perl script that I wrote using DBI and the PG DBD. Looks
like these are the versions...
/tool/pandora64/.package/perl-5.18.2-gcc481/lib/site_perl/5.18.2/x86_64-linux-thread-multi/Bundle/DBI.pm
/tool/pandora64/.package/perl-5.18.2-gcc481/lib/site_perl/5.18.2/x86_64-linux-thread-multi/DBD/Pg.pm
I put print statements around the DB connection code to get a sense of
what's happening there. Sometimes it connects right away, sometimes
there's a delay of a few seconds, sometimes it times out with an error. If
it does connect, sometimes it appears the connection will be dropped.
Where in the code it is dropped can vary. It's not malformed sql code or
anything like that. The error trapping (printing $dbh->err() ) returns
nothing. (I tested this code by giving it a malconstructed query using a
different script and it gives me plenty !). So I think the error trapping
code is OK
I shut down and restarted the DB instance. No difference.
The DB log file back on the server side is replete with...
"could not receive data from client: Connection reset by peer "
followed by
"incomplete startup package"
messages....
LOG: database system was shut down at 2018-02-03 22:46:39 EST
LOG: database system is ready to accept connections
LOG: autovacuum launcher started
LOG: could not receive data from client: Connection reset by peer
LOG: incomplete startup packet
LOG: could not receive data from client: Connection reset by peer
LOG: incomplete startup packet
LOG: could not receive data from client: Connection reset by peer
LOG: incomplete startup packet
LOG: could not receive data from client: Connection reset by peer
LOG: incomplete startup packet
LOG: could not receive data from client: Connection reset by peer
LOG: incomplete startup packet
LOG: could not receive data from client: Connection reset by peer
LOG: incomplete startup packet
LOG: could not receive data from client: Connection reset by peer
LOG: incomplete startup packet
LOG: could not receive data from client: Connection reset by peer
LOG: incomplete startup packet
LOG: could not receive data from client: Connection reset by peer
LOG: incomplete startup packet
LOG: could not receive data from client: Connection reset by peer
LOG: incomplete startup packet
LOG: could not receive data from client: Connection reset by peer
LOG: incomplete startup packet
LOG: could not receive data from client: Connection reset by peer
LOG: incomplete startup packet
LOG: could not receive data from client: Connection reset by peer
LOG: incomplete startup packet
LOG: could not receive data from client: Connection reset by peer
LOG: incomplete startup packet
LOG: could not receive data from client: Connection reset by peer
LOG: incomplete startup packet
If it makes a difference, this problem seemed to begin when I created a
second DB on the instance.
I don't seem to have a problem connecting to the DB from the client side
using good-ole psql. It's always fast and stays
The last clue I can think of is if the initial DB connection times out, a
quick re-invocation of the script connects immediately (as if the first
primed it in some way).
Again, the client is a virtual machine, but the server is on metal.
Any help would be appreciated!
Thanks
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2018-02-07 14:47:05 | Re: "could not receive data from client" && "incomplete startup packet" |
Previous Message | Lazaro Garcia | 2018-02-07 14:28:34 | RE: PostgreSQL Active-Active |