Hello all. First, I'd like to appreciate with all your reviewing and discussion in the last CommitFest[1].
I don't think that the rest one of my proposals has been rejected completely, so I want to restart discussion. It is a timeout parameter in interfaces/libpq. Consider some situations where some happening occurred a server and it became significant busy. e.g., what I and Tsunakawa-san have illustrated[2][3]. These server's bad condition(i.e., non-functional server) could cause clients' infinite waiting because it is not always possible for current timeout parameters in backend side to fire. Under such server's bad condition, control should be passed to the client after a certain period of time, and just a timeout disconnection corresponds to it. Also, in such situations the backend parameters may not work, so we need to implement the timeout parameters on the client side. It is preferable to implement this parameter in PQwait() where clients can wait endlessly. However this can do unintended timeout when setting socket_timeout < statement_timeout(etc. some other timeout parameters). Thus documentation warns this. FYI, a similarly parameter socketTimeout is in pgJDBC[4]. Do you have any thoughts? P.S. Fabien-san, I'll build another thread and let's discussion there about \c's taking care of connection parameters you have pointed out! [1] https://www.postgresql.org/message-id/flat/EDA4195584F5064680D8130B1CA91C45367328@G01JPEXMBYT04 [2] https://www.postgresql.org/message-id/EDA4195584F5064680D8130B1CA91C45367328%40G01JPEXMBYT04 [3] https://www.postgresql.org/message-id/0A3221C70F24FB45833433255569204D1FBC7561%40G01JPEXMBYT05 [4] https://jdbc.postgresql.org/documentation/head/connect.html#connection-parameters Best regards, --------------------- Ryohei Nagaura
socket_timeout.patch
Description: socket_timeout.patch