RE: Timeout parameters
От | Tsunakawa, Takayuki |
---|---|
Тема | RE: Timeout parameters |
Дата | |
Msg-id | 0A3221C70F24FB45833433255569204D1FB9EDCB@G01JPEXMBYT05 обсуждение исходный текст |
Ответ на | RE: Timeout parameters ("Nagaura, Ryohei" <nagaura.ryohei@jp.fujitsu.com>) |
Список | pgsql-hackers |
From: Nagaura, Ryohei [mailto:nagaura.ryohei@jp.fujitsu.com] > > Maybe. Could you suggest good description? > Clients wait until the socket become readable when they try to get results > of their query. > If the socket state get readable, clients read results. > (See src/interfaces/libpq/fe-exec.c, fe-misc.c) > The current pg uses poll() to monitor socket states. > "socket_timeout" is used as timeout argument of poll(). > (See [1] about poll() and its arguments) > > Because "tcp_user_timeout" handles the timeout before and after the above > procedure, > there are different monitoring target between "socket_timeout" and > "tcp_user_timeout". > When the server is saturated, "statement_timeout" doesn't work while > "socket_timeout" does work. > In addition to this, the purpose of "statement_timeout" is to reduce > server's burden, I think. OK, I understand your intent. What I asked Kirk-san is to suggest a description for socket_timeout parameter that the userwould see in PostgreSQL documentation. > My proposal is to enable clients to release their resource which is used > communication w/ the saturated server. I thought the primary purpose is to prevent applications from hanging too long, so that the user does not have to wait infinitely. Releasing resources is a secondary purpose. Regards Takayuki Tsunakawa
В списке pgsql-hackers по дате отправления: