Re: when the startup process doesn't (logging startup delays)

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: when the startup process doesn't (logging startup delays)
Дата
Msg-id CA+TgmoY6rBnAmyxfYoT8byiprvzMM=D_U2iTz9tGa_EdBjnB-Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: when the startup process doesn't (logging startup delays)  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Ответы Re: when the startup process doesn't (logging startup delays)  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Список pgsql-hackers
On Wed, Sep 29, 2021 at 1:36 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> Why is it that we set the next timeout to fire not at "now + interval"
> but at "when-it-should-have-fired-but-didn't + interval"?  As a user, if
> I request a message to be logged every N milliseconds, and one
> of them is a little bit delayed, then (assuming I set it to 10s) I still
> expect the next one to occur at now+10s.  I don't expect the next at
> "now+5s" if one is delayed 5s.

Well, this was my suggestion, because if you don't do this, you get
drift, which I think looks weird. Like the timestamps will be:

13:41:05.012456
13:41:15.072484
13:41:25.149632

...and it gets further and further off as it goes on.'

I guess my expectation is different from yours: I expect that if I ask
for a message every 10 seconds, the time between messages is going to
be 10s, at least on average, not 10s + however much latency the system
has.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: when the startup process doesn't (logging startup delays)
Следующее
От: Justin Pryzby
Дата:
Сообщение: Re: when the startup process doesn't (logging startup delays)