From: | Jan Wieck <janwieck(at)yahoo(dot)com> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Bruce Badger <bbadger(at)BadgerSE(dot)com>, pgsql-interfaces(at)postgresql(dot)org |
Subject: | Re: Beating Oracle |
Date: | 2002-03-01 14:47:16 |
Message-ID: | 200203011447.g21ElGD08399@saturn.janwieck.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-interfaces |
Bruce Momjian wrote:
> TCP has it's own restart logic that will handle the dropping of some
> packets, but if the TCP connection itself shuts down, PostgreSQL has no
> way of reestablishing it.
Yupp, and it already has spent some time trying to retransmit
lost packets in order to keep this connection alive, before
telling "sorry, lost contact".
Do we want to decide dynamically, maybe based on the number
of row locks the current transaction holds, what a good
amount of time for trying to reconnect is? I mean, someone
else might wait for these rows to be available again. Maybe
even the same user, because his client library decided
earlier that the connection is lost, unfortunately some
"reestablish packets" drowned in the net too, but his app
finally succeeded in connecting to a new backend.
If you have connection aborts, the client and application
code is the wrong place to fix. In the "golden era", 95% of
all connectivity problems used to be cables or plugs. These
days, firewalls take care that increased reliability of
cables and plugs doesn't increase overall network
reliability.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-03-01 14:53:19 | Re: Beating Oracle |
Previous Message | Ted Petrosky | 2002-03-01 13:28:37 | help understanding libpq++ |