From: | "Nagaura, Ryohei" <nagaura(dot)ryohei(at)jp(dot)fujitsu(dot)com> |
---|---|
To: | 'Fabien COELHO' <coelho(at)cri(dot)ensmp(dot)fr>, "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org> |
Cc: | "AYahorau(at)ibagroup(dot)eu" <AYahorau(at)ibagroup(dot)eu> |
Subject: | RE: Timeout parameters |
Date: | 2018-12-06 05:19:57 |
Message-ID: | EDA4195584F5064680D8130B1CA91C453A32DB@G01JPEXMBYT04 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)hostname:port/dbname?tcp_user_timeout=15000
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
Attachment | Content-Type | Size |
---|---|---|
document.patch | application/octet-stream | 1.8 KB |
TCP_backend.patch | application/octet-stream | 4.2 KB |
TCP_interface.patch | application/octet-stream | 3.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2018-12-06 05:42:53 | Re: zheap: a new storage format for PostgreSQL |
Previous Message | Amit Langote | 2018-12-06 05:00:22 | Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0 |