Re: Beating Oracle
От | Tom Lane |
---|---|
Тема | Re: Beating Oracle |
Дата | |
Msg-id | 246.1015011606@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Beating Oracle (Tom Ivar Helbekkmo <tih@kpnQwest.no>) |
Ответы |
Re: Beating Oracle
|
Список | pgsql-interfaces |
Tom Ivar Helbekkmo <tih@kpnQwest.no> writes: > So, Bruce might still be bothered with something like that, and/or > (for all he's given us of details) he might actually be talking about > a situation where Oracle will wait through severely prolonged outages > where PostgreSQL won't. I believe that Oracle uses its own networking code (SQLNet) which might well have different error response behavior than TCP does. Still, it's hard to believe that even a broken TCP stack will not hold connections through short- or moderate-duration network glitches; and Bruce did not say that he was trying to deal with multiple-hour outages. I have been wondering about whether Bruce's problem is firewall misbehavior. In particular, if there's a NAT translation happening anywhere between his client and his server, then the firewall could break the connection by dropping that particular port mapping, which perhaps it might do if there's no activity for awhile. In this case, it might actually be that the default KEEPALIVE timeout of 2 hours is too long for us :-(. (RFC 1122 says that the timeout shall be configurable, but this requirement seems to be widely ignored.) As for why Oracle doesn't suffer the same problem, someone suggested that the firewall might be specially configured not to drop Oracle connections (or perhaps to pass them through without NAT mapping). I don't know enough about SQLNet to know what to look for. regards, tom lane
В списке pgsql-interfaces по дате отправления: