Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> This is a network-level issue: the TCP stack on your machine knows the
>> connection has been closed, but it hasn't seen an acknowledgement of
>> that fact from the other machine, and so it's remembering the connection
>> number so that it can definitively say "that connection is closed" if
>> the other machine asks.
> No, what Tom's describing is a different pair of states called FIN_WAIT_1 and
> FIN_WAIT_2. TIME_WAIT isn't waiting for a packet, just a timeout.
D'oh, obviously it's been too many years since I read Stevens ;-)
So AFAICS this status report doesn't actually indicate any problem,
other than massively profligate use of separate connections. Greg's
correct that there's some risk of resource exhaustion at the TCP level,
but it's not very likely. I'd be more concerned about the amount of
resources wasted in starting a separate Postgres backend for each
connection. PG backends are fairly heavyweight objects --- if you
are at all concerned about performance, you want to get a decent number
of queries done in each connection. Consider using a connection pooler.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match