Re: when the startup process doesn't (logging startup delays) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: when the startup process doesn't (logging startup delays)
Date
Msg-id 2992585.1632938816@sss.pgh.pa.us
Whole thread Raw
In response to Re: when the startup process doesn't (logging startup delays)  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: when the startup process doesn't (logging startup delays)
List pgsql-hackers
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> On 2021-Sep-29, Robert Haas wrote:
>> 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.'

> Right ... I actually *expect* this drift to occur.  Maybe people
> generally don't like this, it just seems natural to me.  Are there other
> opinions on this aspect?

FWIW, I agree with Robert that it's nicer if the timeout doesn't drift.
There's a limit to how much complexity I'm willing to tolerate for that,
but it doesn't seem like this exceeds it.

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.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [BUG] failed assertion in EnsurePortalSnapshotExists()
Next
From: Ranier Vilela
Date:
Subject: Re: [BUG] failed assertion in EnsurePortalSnapshotExists()