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+TgmoZ3ZXqBQ1WSEn-Vo0+8V-8eAUO-fJcCmVUQ54Ecc6zNPQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: when the startup process doesn't (logging startup delays)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: when the startup process doesn't (logging startup delays)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Wed, Sep 29, 2021 at 2:06 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> The real comment I'd have here, though, is that writing one-off
> code for this purpose is bad.  If we have a need for a repetitive
> timeout, it'd be better to add the feature to timeout.c explicitly.
> That would probably also remove the need for extra copies of the
> timeout time.

I'm not sure that really helps very much, honestly.  I mean it would
be useful in this particular case, but there are other cases where we
have logic like this already, and this wouldn't do anything about
those. For example, consider autoprewarm_main(). Like this code, that
code thinks (perhaps just because I'm the one who reviewed it) that
the next time should be measured from the last time ... but an
enhancement to the timeout machinery wouldn't help it at all. I
suspect there are other cases like this elsewhere, because this is
what I personally tend to think is the right behavior and I feel like
it comes up in patch reviews from time to time, but I'm not finding
any at the moment. Even if I'm right that they exist, I'm not sure
they look much like each other or can easily reuse any code.

And then again on the other hand, BackgroundWriterMain() thinks that
the next time should be measured from the time we got around to doing
it, not the scheduled time. I guess we don't really have any
consistent practice here.

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



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

Предыдущее
От: David Christensen
Дата:
Сообщение: Re: DELETE CASCADE
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: prevent immature WAL streaming