> PG *will* close the connection immediately if it receives any
> notification of connection drop from the client. If it's not seeing
> one, that suggests something wrong in your network infrastructure.
> I'd suggest fixing the problem rather than kluging the symptom.
I have W2K server running also Exchange and other applications. I havent
seen any problem with other appls.
In every morning 8 persons from different locations over internet each open
a single TCP connection to this
Postgres 8.1.3 server using ODBC. They close my appl in midnight.
Every day some clients receive randomly error form ODBC driver
SQL state: 08S01
Error number: 27
Message:
"Error while executing the query; server closed the connection unexpectedly
This probably means the
server terminated abnormally before or while processing the request."
In fewer cases error message is
"Could not send query to backend;Could not send query to backend"
In this case my application sends disconnect command to ODBC driver and
re-connects.
Re-connect is OK.
After first error I see that there are 2 Postgres processes running for that
user.
Clients are using ADSL connection over phone line maintained by phone
company and I have no control over this.
Doe to design request my application checks for duplicate connections and
those dupl connections prevent working.
Any idea what should I change?
> You can reduce the TCP timeout settings if you are using PG 8.1 and an
> operating system that supports it (I have no idea if Windows does or not).
> I wouldn't recommend trying to make it "immediate" since then any
> network instability breaks your application. 5 minutes or so might be
> reasonable though. As you've noticed, the default timeouts are usually
> upwards of an hour. (You should however ask yourself if you really know
> more about TCP than the authors of the TCP specifications do.)
My queries do not take more time than 5 minutes.
In case of connection loss application re-connects automatically.
What are reasonable values of the 3 TCP_KEEPALIVE_* parameters in this case
?
Andrus.