From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Lukas Fittl <lukas(at)fittl(dot)com> |
Subject: | Re: enable_timeout_every() and fin_time |
Date: | 2023-01-03 20:14:00 |
Message-ID: | 20230103201400.bo5uq2tuu2qye2bz@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2023-01-03 20:19:43 | Re: postgres_fdw uninterruptible during connection establishment / ProcSignalBarrier |
Previous Message | Robert Haas | 2023-01-03 20:11:47 | Re: fixing CREATEROLE |