RE: Timeout parameters
| От | MikalaiKeida@ibagroup.eu |
|---|---|
| Тема | RE: Timeout parameters |
| Дата | |
| Msg-id | OF4918EAD0.A1F2C472-ON432583BA.003102FD-432583BA.0032191B@iba.by обсуждение исходный текст |
| Ответ на | RE: Timeout parameters ("Nagaura, Ryohei" <nagaura.ryohei@jp.fujitsu.com>) |
| Ответы |
RE: Timeout parameters
|
| Список | pgsql-hackers |
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
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
В списке pgsql-hackers по дате отправления: