enable_timeout_every() and fin_time

From: Andres Freund <andres(at)anarazel(dot)de>
To: pgsql-hackers(at)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Lukas Fittl <lukas(at)fittl(dot)com>
Subject: enable_timeout_every() and fin_time
Date: 2023-01-02 00:36:18
Message-ID: 20230102003618.hnynyexncxanuepg@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


I was looking using enable_timeout_every() in another place with Lukas
just now, and noticed the fin_time argument. It seems odd for an
interval firing interface to get an absolute timestamp as an
argument. The only in-tree user of enable_timeout_every() computes
fin_time explicitly using the interval time:

startup_progress_phase_start_time = GetCurrentTimestamp();
fin_time = TimestampTzPlusMilliseconds(startup_progress_phase_start_time,
enable_timeout_every(STARTUP_PROGRESS_TIMEOUT, fin_time,

In https://postgr.es/m/CA%2BTgmoYqSF5sCNrgTom9r3Nh%3Dat4WmYFD%3DgsV-omStZ60S0ZUQ%40mail.gmail.com
Robert said:
> Apparently not, but here's a v2 anyway. In this version I made
> enable_timeout_every() a three-argument function, so that the caller
> can specify both the first time at which the timeout routine should be
> called and the interval between them, instead of only the latter. That
> seems to be more convenient for this use case, and is more powerful in
> general.

What is the use case for an absolute start time plus a relative

ISTM that this will just lead to every caller ending up with a
calculation like the startup.c piece quoted above.


Andres Freund


Browse pgsql-hackers by date

  From Date Subject
Next Message Imseih (AWS), Sami 2023-01-02 04:34:26 Re: Add index scan progress to pg_stat_progress_vacuum
Previous Message Andrew Dunstan 2023-01-01 23:34:13 Re: Announcing Release 15 of the PostgreSQL Buildfarm client