From: Kyotaro HORIGUCHI [mailto:horiguchi.kyotaro@lab.ntt.co.jp]
> If so, in turn the socket_timeout doesn't work as expected? I
> understand that what is proposed here is to disconnect after that
> time of waiting for *the first tuple* of a query, regardless of
> it is a long query or network failure. On of the problems raised
> here is the socket_timetout patch doesn't work that way?
No, the proposal is to set the timeout for every socket read/write like PgJDBC. It is not restricted to an SQL command
execution;it applies to any communication with the server that could block the client.
> I can't imagine that in the cases where other than applications
> cannot be rebuild for some reasons. (E.g. the source code has
> been lost or the source code no longer be built on modern
> environment..)
>
> If an application is designed to have such a requirement, mustn't
> it have implemented that by itself by any means? For example, an
> application on JDBC can be designed to kill a querying thread
> that takes longer than threshold.
Any paid or free applications whose source code is closed. Also, ordinary users don't want to modify psql and pgAdmin
sourcecode by themselves, do they?
> Doesn't TCP_KEEPALIVE work that way?
>
> statement_timeout works on a live connection, TCP_USER_TIMEOUT
> works for an already failed network but if the network fails
> after a backend already sent the ack for a query request, it
> doesn't work. TCP_KEEPALIVE would work for the case where any
> packet doesn't reach each other for a certain time. Is there any
> other situations to save?
For example, OS issues such as abnormally (buggy) slow process scheduling or paging/swapping that prevent control from
beingpassed to postgres. Or, abnormally long waits on lwlocks in postgres. statement_timeout doesn't take effect
whilewaiting on a lwlock. I have experienced both. And, any other issues in the server that we haven't experienced
andnot predictable.
Regards
Takayuki Tsunakawa
