Hi, There was an invisible space, so I removed it. I registered with 2019-01 commitfest.
Best regards, --------------------- Ryohei Nagaura > -----Original Message----- > From: Nagaura, Ryohei [mailto:nagaura.ryo...@jp.fujitsu.com] > Sent: Thursday, December 6, 2018 2:20 PM > To: 'Fabien COELHO' <coe...@cri.ensmp.fr>; > 'pgsql-hack...@postgresql.org' <pgsql-hack...@postgresql.org> > Cc: Yahorau, A. (IBA) <ayaho...@ibagroup.eu> > Subject: RE: Timeout parameters > > Hi, Fabien. > > Thank you for your review. > And I'm very sorry to have kept you waiting so long. > > > About "socket_timeout" > > > I'm generally fine with giving more access to low-level parameters to > users. > > However, I'm not sure I understand the use case you have that needs > > these new extensions. > If you face the following situation, this parameter will be needed. > 1. The connection between the server and the client has been established > normally. > 2. A server process has been received SQL statement. > 3. The server OS can return an ack packet, but it takes time to execute > the SQL statement > Or return the result because the server process is very busy. > 4. The client wants to close the connection while leaving the job to the > server. > In this case, "statement_timeout" can't satisfy at line 4. > > > I think that there is some kind of a misnomer: this is not a > > socket-level timeout, but a client-side query timeout, so it should be > named differently? > Yes, I think so. > > > I'm not sure how to name it, though. > Me too. > > > I think that the way it works is a little extreme, basically the > > connection is aborted from within pqWait, and then restarted from scratch. > > > > There is no clear way to know about the value of the setting (SHOW, > > \set, \pset...). Ok, this is already the case of other connection > parameters. > If this parameter can be needed, I would like to discuss design and optional > functions. > How do you think? > I'll correct patch of "socket_timeout" after that. > > > About "TCP_USER_TIMEOUT" > I fixed on the previous feedback. > Would you review, please? > > > There are no tests. > I introduce the test methods of TCP_USER_TIMEOUT. > > Test of client-side TCP_USER_TIMEOUT: > [client operation] > 1. Connect DB server. > postgres=# psql > postgresql://USERNAME:PASSWORD@hostname:port/dbname?tcp_user_timeout=1 > 5000 > 2. Get the port number by the following command: > postgres=# select inet_client_port(); > 3. Close the client port from the other console of the client machine. > Please rewrite "56750" to the number confirmed on line 2. > $ iptables -I INPUT -p tcp --dport 56750 -j DROP 4. Query the > following SQL: > postgres=# select pg_sleep(10); > 5. TCP USER TIMEOUT works correctly if an error message is output to the > console. > > Test of server-side TCP_USER_TIMEOUT: > [client operation] > 1. Connect DB server. > 2. Get the port number by the following command: > postgres=# select inet_client_port(); > 3. Set the TCP_USER_TIMEOUT by the following command: > postgres=# set tcp_user_timeout=15000; > 4. Query the following SQL: > postgres=# select pg_sleep(10); > 5. Close the client port from the other console. > Please rewrite "56750" to the number confirmed on line 2. > $ iptables -I INPUT -p tcp --dport 56750 -j DROP [server operation] > 6. Verify the logfile. > > > There is no documentation. > I made a patch of documentation of TCP USER TIMEOUT. > > Best regards, > --------------------- > Ryohei Nagaura
document_v2.patch
Description: document_v2.patch
TCP_backend_v2.patch
Description: TCP_backend_v2.patch
TCP_interface_v2.patch
Description: TCP_interface_v2.patch
