Hello Ryohei-san,

I understand the main aim of your suggestion that a client application has 
to do a lot of work except making quires to the database. I agree with you 
that "client-side timeout" has to be integrated into the PostgreSQL server 
and libpq.
I'm with Fabien that "client-side timeout" seems unsafe. Also I agree with 
Fabien that quire can take much time to be processed by the PosgtreSQL 
server and it is a normal behavior. There is possible that performance of 
the PostgreSQL server machine can be low temporary or continuously, 
especially during upgrading procedure.
I think it is important to add some more information into the description 
of this parameter which informs end-users that this parameter has to be 
used very carefully because it can impact as on the client application as 
on the server.

> You mentioned about when a SQL query is heavy, but I want to talk about 
when OS hang.
> If OS hang occurs, the cost of cancel request processing is so high.

Such a situation looks to be covered by TCP_USER_TIMEOUT and keep_alive 
mechanisms. May be it is better to warn in documentation or prohibit in 
the source code to set "client-side timeout" less than TCP_USER_TIMEOUT to 
avoid handling "possible" logical problems ahead to the network problems. 
Keep in mind that   "client-side timeout" can abort a connection which 
uses UNIX-domain sockets too.

What do you think about it?

Best regards,
Mikalai Keida

Reply via email to