Greg Stark <gsstark@xxxxxxx> writes: > On Thu, Jan 28, 2010 at 8:55 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: >> In general, sockets sitting a long time in TIME_WAIT would be a network >> problem. That state means the user process already closed the socket >> and the network stack is waiting for the other end to acknowledge >> connection closure. > I think you're describing FIN_WAIT. TIME_WAIT is after the finack has > been sent and the connection is well and truly dead. The same > host/port pair can't be reused for 2*msl in case the finack needs to > be resent or a duplicate fin arrives. > Normally the server uses SO_LINGER and skips TIME_WAIT so it can > listen on the same port immediately and accept more connections. So > only the client enters TIME_WAIT and its for some random high-numbered > port that the OS won't hand out until it expires. Hmm. This may well be a platform-specific behavior of the network stack. On my mail machine (running a pretty ancient HPUX release) I can normally see a dozen or so inbound connections to port 25 that are sitting in TIME_WAIT state, probably reflecting spambots that didn't bother to close the connection gracefully. It's possible that a newer network stack would bypass that state. But in any case the userland process has definitely dropped the connection, right? So it's not Postgres' issue, it's a networking issue. regards, tom lane -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
