[patch]socket_timeout in interfaces/libpq

From: "nagaura(dot)ryohei(at)fujitsu(dot)com" <nagaura(dot)ryohei(at)fujitsu(dot)com>
To: "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org>
Cc: "k(dot)jamison(at)jp(dot)fujitsu(dot)com" <k(dot)jamison(at)jp(dot)fujitsu(dot)com>, 'Fabien COELHO' <coelho(at)cri(dot)ensmp(dot)fr>, 'Kyotaro HORIGUCHI' <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, "'robertmhaas(at)gmail(dot)com'" <robertmhaas(at)gmail(dot)com>, "MikalaiKeida(at)ibagroup(dot)eu" <MikalaiKeida(at)ibagroup(dot)eu>, "AYahorau(at)ibagroup(dot)eu" <AYahorau(at)ibagroup(dot)eu>, 'Michael Paquier' <michael(at)paquier(dot)xyz>, "tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>
Subject: [patch]socket_timeout in interfaces/libpq
Date: 2019-06-26 04:13:36
Message-ID: OSAPR01MB39407103549D0AAFE0A5A3F996E20@OSAPR01MB3940.jpnprd01.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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(at)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

Attachment Content-Type Size
socket_timeout.patch application/octet-stream 4.9 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message nagaura.ryohei@fujitsu.com 2019-06-26 04:14:45 inheritance of connection paramters when using \c
Previous Message Michael Paquier 2019-06-26 04:11:31 Re: fsync error handling in pg_receivewal, pg_recvlogical