Bruce Badger <bbadger@BadgerSE.com> writes:
> The thing is that from their point of view, Oracle keeps going where
> PostgreSQL does not. Given that both are running over the same network,
> the response of these people could well be to simply move everything to
> Oracle.
<shrug> If that feature makes Oracle worth its price to them, then
no doubt that's what they'll do. Postgres doesn't have 6000 full-time
developers engaged in inventing bizarre features (and a substitute for
something that should be done at the network level is bizarre in my
book).
The reason I'm so unenthused about this is that I think it'd be quite
difficult to do transparently at the database level. (1) How can you
know where communication was lost, from the other end's point of view?
(eg, client has no idea whether database completed the last request
sent.) I think you'd wind up reimplementing TCP, or something much like
it, just to deal with that aspect of the problem. (2) How can you even
be sure that you're reconnecting to the same other-end session?
Opportunities for security holes seem rampant. (3) Should the database
hold sessions open indefinitely, waiting to see if the client can be
recontacted? Won't take too long until your session limit is entirely
filled by dead connections.
Non-broken TCP stacks are normally quite tenacious about surviving
transmission glitches in already-open connections. I think you ought
to be looking for solutions at that level, not trying to tell us that
it's our problem.
regards, tom lane