RE: Timeout parameters

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