Re: Beating Oracle

Tom Lane wrote:

>Bruce Badger <bbadger(at)BadgerSE(dot)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
>
Ah, Tom. I'm not demanding anything, nor saying this is any
individual's problem. I was merely seeking the wisdom of others, and I
am grateful for your feedback (apart from the bits that slap me for
something I have not done ;-) ).

FWIW, I too have invested a great deal of my own time in making
PostgreSQL available to others, having built and supported the Smalltalk
PostgreSQL library.