Re: enable_timeout_every() and fin_time
От | Andres Freund |
---|---|
Тема | Re: enable_timeout_every() and fin_time |
Дата | |
Msg-id | 20230103201400.bo5uq2tuu2qye2bz@awork3.anarazel.de обсуждение исходный текст |
Ответ на | Re: enable_timeout_every() and fin_time (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: enable_timeout_every() and fin_time
|
Список | pgsql-hackers |
Hi, On 2023-01-03 13:33:34 -0500, Robert Haas wrote: > On Sun, Jan 1, 2023 at 7:36 PM Andres Freund <andres@anarazel.de> wrote: > > What is the use case for an absolute start time plus a relative > > interval? > > The code snippet that you indicate has the important side effect of > changing the global variable startup_progress_phase_start_time, which > is used by has_startup_progress_timeout_expired. Without the fin_time > argument, the timeout machinery would have to call > GetCurrentTimestamp() separately, and the caller wouldn't know what > answer it got. The result would be that the progress reports would > indicate an elapsed time relative to one timestamp, but the time at > which those progress reports were printed would be relative to a > slightly different timestamp. > Maybe nobody would notice such a minor discrepancy, but I wanted to avoid it. Doesn't that discrepancy already exist as the code stands, because startup_progress_phase_start_time is also set in has_startup_progress_timeout_expired()? I realize that was an example, but the issue seems broader: After the first "firing", the next timeout will be computed relative to an absolute time gathered in timestamp.c. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: