RE: [patch]socket_timeout in interfaces/libpq
Hi, Michael-san. Sorry, I have missed your e-mail... > From: Michael Paquier > On Wed, Jun 26, 2019 at 11:56:28AM +, nagaura.ryo...@fujitsu.com wrote: > > It seems that you did not think so at that time. > > # Please refer to [1] > > > > I don't think all the reviewers are completely negative. > > I recall having a negative impression on the patch when first looking at it, > and still > have the same impression when looking at the last version. Just with a quick > look, assuming that you can bypass all cleanup operations normally taken by > pqDropConnection() through a hijacking of pqWait() is not fine as this routine > explicitely assumes to *never* have a timeout for its wait. I couldn't understand what you meant. Do you say that we shouldn't change pqWait() behavior? Or should I modify my patch to use pqDropConnection()? Best regards, - Ryohei Nagaura
inheritance of connection paramters when using \c
Hello! \c is followed by [-reuse-previous=on/off] positional syntax | conninfo Using \c -reuse-previous=on positional syntax or \c positional syntax without -reuse-previous option, some parameters which were omitted or notated as "-" will be reused in the new connection. The target is only "dbname", "user", "host", "port" in the current implementation. # details in [1] When we discussed in [2], this topic came out. Although I'm not heavy psql user, I want it to inherit connection parameters and Fabien-san does too. My new specification: \c inherits all the unspecified connection parameters in PQconninfoOptions in cases below. a) \c -reuse-previous=on positional syntax b) \c positional syntax This is just an expansion of the target of inheritance of parameters from the current specification. I have an item to talk about. It is whether the message which indicates connection information to users has to have more information such as You are now connected to database "TomANDJelly" as user "nyannyan" with some parameters [reused | defaults]. # after "nyannyan" Do you have any thoughts? [1] https://www.postgresql.org/docs/12/app-psql.html [2] https://www.postgresql.org/message-id/flat/EDA4195584F5064680D8130B1CA91C45367328@G01JPEXMBYT04 Best regards, - Ryohei Nagaura
[patch]socket_timeout in interfaces/libpq
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
RE: [patch]socket_timeout in interfaces/libpq
Hi, Michael-san. > From: Michael Paquier > On Wed, Jun 26, 2019 at 04:13:36AM +, nagaura.ryo...@fujitsu.com wrote: > > I don't think that the rest one of my proposals has been rejected > > completely, so I want to restart discussion. > I recall on the matter that there was consensus that nobody really liked this > option > because it enforced a cancellation on the connection. It seems that you did not think so at that time. # Please refer to [1] I don't think all the reviewers are completely negative. I think some couldn't judge because lack of what kind of problem I was going to solve and the way to solve it, so I restarted to describe them in this time. [1] https://www.postgresql.org/message-id/20190406065428.GA2145%40paquier.xyz Best regards, - Ryohei Nagaura
