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
connectingto 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@Yahoo.com #
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
