<cswi...@mac.com> aka Chuck Swiger schrieb mit Datum Fri, 17 Jul 2009 13:49:10 -0700 in m2n.fbsd.stable:
|On Jul 17, 2009, at 12:12 PM, Peter Much wrote: |[ ... ] |> One other thing did happen between 03:51 and 03:52 - the DSL |> internet connection did disconnect/reconnect and obtained a new |> IP adress. Afterwards, a script does flush and reload an ipfw table() |> with the new local adresses - and during this process one(!) packet |> of the database session was dropped. | |Well, there you go: having your IP change is certainly going to break |existing network connections; Uh, is that so? Maybe I wasnt clear enough: the failing database connection is a LOCALHOST-LOCALHOST connection - and it uses the (fixed) IP of one of the LAN interfaces, not the dynamic internet IP on the tun/PPP interface. Changing the IP on one interface while using another interface is, to all my knowledge, normal business. And even IF there were problem with that, then I would expect the connection to timeout and fail, I would NOT expect a memory leak to appear and drive the system out of swap within seconds. !I don't believe there is anything which |is going to move the existing connection state in a NAT translation |layer or whatever over to the new IP. Nay, that doesnt work. |Presumably you can obtain a |static IP and avoid such issues. I have a static internet IP on the machine, also, for HTTPS. I have lots of interfaces there. And I did run some tests in the meantime. The problem is in the PostgresQL library; it doesnt depend on a changed IP; - I only need to steal one packet out of the transmission, then the database client will grow to VSZ=1500GB and bigger. That's perfect reproduceable. The postgresQL is 8.2, rather old by now - but I really wonder that noone else did get into this during all the time. rgds, PMc _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
