RE: Timeout parameters

Поиск
Список
Период
Сортировка
От Nagaura, Ryohei
Тема RE: Timeout parameters
Дата
Msg-id EDA4195584F5064680D8130B1CA91C453A32DB@G01JPEXMBYT04
обсуждение исходный текст
Ответ на Re: Timeout parameters  (Fabien COELHO <coelho@cri.ensmp.fr>)
Ответы RE: Timeout parameters  ("Nagaura, Ryohei" <nagaura.ryohei@jp.fujitsu.com>)
RE: Timeout parameters  ("Nagaura, Ryohei" <nagaura.ryohei@jp.fujitsu.com>)
Список 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@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


Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: Use durable_unlink for .ready and .done files for WAL segmentremoval
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: zheap: a new storage format for PostgreSQL