RE: Timeout parameters - Mailing list pgsql-hackers

From Tsunakawa, Takayuki
Subject RE: Timeout parameters
Date
Msg-id 0A3221C70F24FB45833433255569204D1FBC7FD1@G01JPEXMBYT05
Whole thread Raw
In response to RE: Timeout parameters  (MikalaiKeida@ibagroup.eu)
Responses RE: Timeout parameters
List pgsql-hackers
From: MikalaiKeida@ibagroup.eu [mailto:MikalaiKeida@ibagroup.eu]
> In case of failure PQcancel() terminates in 'socket_timeout'. So, control
> to the end-user in such a failure situation will be returned in 2 *
> 'socket_timeout' interval. It is much better than hanging forever in some
> specific cases. Moreover, such solution will not lead to the overloading
> of PostgreSQL server by abnormally ignored 'heavy' queries results by
> end-users.

Oops, unfortunately, PQcancel() does not follow any timeout parameters...  It uses a blocking socket.

Also, I still don't think it's a good idea to request cancellation.  socket_timeout should be sufficiently longer than
theusually expected query execution duration.  And long-running queries should be handled by statement_timeout which
indicatesthe maximum tolerable query execution duration.
 
For example, if the usually expected query execution time is 100 ms, statement_timeout can be set to 3 seconds and
socket_timeoutto 5 seconds.
 


Regards
Takayuki Tsunakawa






pgsql-hackers by date:

Previous
From: Haribabu Kommi
Date:
Subject: Re: current_logfiles not following group access and instead followslog_file_mode permissions
Next
From: Michael Banck
Date:
Subject: Re: Offline enabling/disabling of data checksums