Re: Patch: add recovery_timeout option to control timeout of restore_command nonzero status code
От | Michael Paquier |
---|---|
Тема | Re: Patch: add recovery_timeout option to control timeout of restore_command nonzero status code |
Дата | |
Msg-id | CAB7nPqT_uwHcL-7_7PD9t-aak+Opx+skfU=UhhLviAYjOGje=A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re[2]: [HACKERS] Patch: add recovery_timeout option to control timeout of restore_command nonzero status code (Alexey Vasiliev <leopard_ne@inbox.ru>) |
Ответы |
Re[2]: [HACKERS] Patch: add recovery_timeout option to control timeout of restore_command nonzero status code
Re: Patch: add recovery_timeout option to control timeout of restore_command nonzero status code |
Список | pgsql-hackers |
On Wed, Dec 31, 2014 at 12:22 AM, Alexey Vasiliev <leopard_ne@inbox.ru> wrote: > Tue, 30 Dec 2014 21:39:33 +0900 от Michael Paquier <michael.paquier@gmail.com>: > As I understand now = (pg_time_t) time(NULL); return time in seconds, what is why I multiply value to 1000 to compare withrestore_command_retry_interval in milliseconds. This way of doing is incorrect, you would get a wait time of 1s even for retries lower than 1s. In order to get the feature working correctly and to get a comparison granularity sufficient, you need to use TimetampTz for the tracking of the current and last failure time and to use the APIs from TimestampTz for difference calculations. > I am not sure about small retry interval of time, in my cases I need interval bigger 5 seconds (20-40 seconds). Right nowI limiting this value be bigger 100 milliseconds. Other people may disagree here, but I don't see any reason to put restrictions to this interval of time. Attached is a patch fixing the feature to use TimestampTz, updating as well the docs and recovery.conf.sample which was incorrect, on top of other things I noticed here and there. Alexey, does this new patch look fine for you? -- Michael
Вложения
В списке pgsql-hackers по дате отправления: