Re: CentOS & PostgreSQL help re: TIME_WAIT
От | Tom Lane |
---|---|
Тема | Re: CentOS & PostgreSQL help re: TIME_WAIT |
Дата | |
Msg-id | 8848.1264793170@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: CentOS & PostgreSQL help re: TIME_WAIT (Greg Stark <gsstark@mit.edu>) |
Список | pgsql-admin |
Greg Stark <gsstark@mit.edu> writes: > On Thu, Jan 28, 2010 at 8:55 PM, Tom Lane <tgl@sss.pgh.pa.us> 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
В списке pgsql-admin по дате отправления: