From: Jamison, Kirk [mailto:k.jami...@jp.fujitsu.com]
> 1) tcp_user_timeout parameter
> I think this can be "committed" separately when it's finalized.
Do you mean you've reviewed and tested the patch by simulating a communication
failure in the way Nagaura-san suggested?
> 2) tcp_socket_timeout parameter
> - whether (a) it should abort the connection from pqWait() or
> other means, or
> (b) cancel the statement similar to how psql
> does it as suggested by Fabien
We have no choice but to terminate the connection, because we can't tell
whether we can recover from the problem and continue to use the connection
(e.g. long-running query) or not (permanent server or network failure).
Regarding the place, pqWait() is the best (and possibly only) place. The
purpose of this feature is to avoid waiting for response from the server
forever (or too long) in any case, as a last resort.
Oracle has similar parameters called SQLNET.RECV_TIMEOUT and
SQLNET.SEND_TIMEOUT. From those names, I guess they use SO_RCVTIMEO and
SO_SNDTIMEO socket options. However, we can't use them because use
non-blocking sockets and poll(), while SO_RCV/SND_TIMEO do ont have an effect
for poll():
[excerpt from "man 7 socket"]
--------------------------------------------------
SO_RCVTIMEO and SO_SNDTIMEO
Specify the receiving or sending timeouts until reporting an
error. The argument is a struct timeval. If an input or output
function blocks for this period of time, and data has been sent
or received, the return value of that function will be the
amount of data transferred; if no data has been transferred and
the timeout has been reached then -1 is returned with errno set
to EAGAIN or EWOULDBLOCK just as if the socket was specified to
be non-blocking. If the timeout is set to zero (the default)
then the operation will never timeout. Timeouts only have
effect for system calls that perform socket I/O (e.g., read(2),
recvmsg(2), send(2), sendmsg(2)); timeouts have no effect for
select(2), poll(2), epoll_wait(2), etc.
--------------------------------------------------
> - proper parameter name
>
> Based from your description below, I agree with Fabien that it's somehow
> the application/client side query timeout
I think the name is good because it indicates the socket-level timeout. That's
just like PgJDBC and Oracle, and I didn't feel strange when I read their
manuals.
> Perhaps you could also clarify a bit more through documentation on how
> socket_timeout handles the timeout differently from statement_timeout
> and tcp_user_timeout.
Maybe. Could you suggest good description?
Regards
Takayuki Tsunakawa
