Brian Wipf writes:
On 12-Dec-06, at 4:30 PM, Tom Lane wrote:
"Brendan O'Shea" <[EMAIL PROTECTED]> writes:
We have discovered a situation where the statement_timeout is not =
honored for broken connections. If a connection is in the process of =
returning results to the client and the connect
"Tom Lane" <[EMAIL PROTECTED]>
"Brendan O'Shea" <[EMAIL PROTECTED]> writes:
We have discovered a situation where the statement_timeout is not =
honored for broken connections. If a connection is in the process of =
returning results to the client and the connection is severed (for =
example, n
On Tue, Dec 12, 2006 at 10:41:19PM -0500, Tom Lane wrote:
> "Brendan O'Shea" <[EMAIL PROTECTED]> writes:
> > Is there no way to specify a timeout for the write() to the socket or some
> > other way to abort?
>
> This is really a question to take up with your TCP stack implementors.
> I think it i
"Brendan O'Shea" <[EMAIL PROTECTED]> writes:
> Is there no way to specify a timeout for the write() to the socket or some
> other way to abort?
This is really a question to take up with your TCP stack implementors.
I think it is fundamentally wrong for Postgres to be second-guessing
the network s
On 12-Dec-06, at 4:30 PM, Tom Lane wrote:
"Brendan O'Shea" <[EMAIL PROTECTED]> writes:
We have discovered a situation where the statement_timeout is not =
honored for broken connections. If a connection is in the process
of =
returning results to the client and the connection is severed (for
"Brendan O'Shea" <[EMAIL PROTECTED]> writes:
> We have discovered a situation where the statement_timeout is not =
> honored for broken connections. If a connection is in the process of =
> returning results to the client and the connection is severed (for =
> example, network cable on client is u
