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  (jtv <jtv@xs4all.nl>)
Список 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 по дате отправления:

Предыдущее
От: Tom Ivar Helbekkmo
Дата:
Сообщение: Re: Beating Oracle
Следующее
От: Jan Wieck
Дата:
Сообщение: Re: Beating Oracle