Re: Beating Oracle

Tom Lane wrote:

>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
>
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.