Dear Nicolas, Dear Robert,

Thank you for your quick answers.
We do not have such behavior using SSL, how do you explain it ?
I suppose that openssl is using the setsockopt SO_LINGER that
removes this behavior. Therefore, there is a RST sent to close
the socket.

We work with an environment that uses a lot of socket connections.
Therefore, many file descriptors are opened. If after each
Sql requests a TIME_WAIT arises we will end up with many
file descriptors opened. By default the maximum number of file descriptors
is set to 1024 and we reach that number quite fast.

Do you have any advices to get rid of this TIME_WAIT problem ?
Our client runs on the same machine as the postgresql server.
Would it be possible to use PF_UNIX sockets ?

Thank you,

Franck


-----Original Message-----
From: Nicolas Barbier
Sent: lundi 27 septembre 2010 18:23
To: Guillaume Du Pasquier
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] client socket TIME_WAIT state after PQfinish

2010/9/27 Guillaume Du Pasquier <guillaume.dupasquier@sensometrix.ch>:
In both cases, the client socket (pgadmin or my program) remains in
TIME_WAIT state.

I have used wireshark to sniff the TCP protocol.

We have at the end of a connection:

Client                  Server

--->    FIN,ACK  --->
<---    FIN,ACK  <---
--->      ACK    --->

This ends up in a TIME_WAIT state. The TCP protocol should be
According to the Two Generals' Problem [1], one of the sides
necessarily doesn't know whether the other side has received its last
packet. Therefore, TCP lets one of the sides sit in TIME_WAIT status
for as long as any packets could in principle survive on the network
(typically defined as 2 minutes on IP networks IIRC), and potentially
disturb a new connection between the same (dst IP, dst port, src IP,
src port) combination.

[1] <URL:http://en.wikipedia.org/wiki/Two_Generals'_Problem>
Client                  Server

--->    FIN,ACK  --->
<---      ACK    <---
<---    FIN,ACK  <---
AFAIK, this last ACK (in above packet) is not needed: the server can
ACK the client's FIN _while_ it sends its own FIN (by using an
appropriate sequence number, as FIN "uses" one byte in the sequence).
--->      ACK    --->

I suppose there is a bug in the postgresql server that do not send an ack to
the client.
I don't think so.

Nicolas

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 4 of 6 | next ›
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedSep 27, '10 at 3:56p
activeSep 27, '10 at 5:49p
posts6
users3
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase