Thread: Port Bug Report: Backend processeses hang when remote connections break.
Port Bug Report: Backend processeses hang when remote connections break.
From
Unprivileged user
Date:
============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================
Your name : Juan Alvarez Ferrando
Your email address : jferrando@acm.org
Category : runtime: back-end
Severity : serious
Summary: Backend processeses hang when remote connections break.
System Configuration
--------------------
Operating System : Linux 2.0.36 ELF (Suse 5.3)
PostgreSQL version : 6.0
Compiler used : Precompiled
Hardware:
---------
Pentium II 333MHZ, 128MB RAM, 4GB SCSI HDD
Versions of other tools:
------------------------
--------------------------------------------------------------------------
Problem Description:
--------------------
When the network connection to the backend breaks (for
example if you pull out the cable from the NIC, or switch
off the modem), the backend process that attended the
connection hangs and never dies. This fills the backend
limit of 64 and the database blocks.
--------------------------------------------------------------------------
Test Case:
----------
Have postgersql configured for TCP/IP connections and
password user identification.
Make a ps in the server to see what backends are opened
(the postgres processes).
Open a frontend or client program that connects to de
database.
Make a query to check that the connection works fine.
Make a ps to get the process that corresponds to your
connection.
Unplug the network cable from the NIC, or switch off the
modem.
Make another query to see how it fails (exception 'Connection reset by peer' when using JDBC).
Make a ps in the server machine and see how the process is
still there.
Plug in the cable again or reconnect to your ISP, and see
how the connection is not restored, so you have to open
a new frontend to get a new database connection (new
process in the server).
As it seems, the TCP/IP connection is broken but the backend
is not informed of this. When a software crash occurs the
backend does dissapear, so it seems a bit strange.
--------------------------------------------------------------------------
Solution:
---------
--------------------------------------------------------------------------