Re: Beating Oracle - Mailing list pgsql-interfaces

From Tom Lane
Subject Re: Beating Oracle
Date
Msg-id 246.1015011606@sss.pgh.pa.us
Whole thread Raw
In response to Re: Beating Oracle  (Tom Ivar Helbekkmo <tih@kpnQwest.no>)
Responses Re: Beating Oracle  (jtv <jtv@xs4all.nl>)
List 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 by date:

Previous
From: Tom Ivar Helbekkmo
Date:
Subject: Re: Beating Oracle
Next
From: Jan Wieck
Date:
Subject: Re: Beating Oracle