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+TgmoZ0Fc_pqFrdTwrJhEPByExxaCMsq9gsW-u02YrXQy02QA@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)
Re: when the startup process doesn't (logging startup delays) |
Список | pgsql-hackers |
On Thu, Sep 30, 2021 at 3:10 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > That would be lovely, certainly. But aren't you moving the goalposts > rather far? I don't think we make any promises about such things > today, so why has the issue suddenly gotten more pressing? Yeah, perhaps it's best to not to worry about it. I dislike failure to worry about that case on general principle, but I agree with you that it seems to be moving the goalposts a disproportionate distance. > In particular, > why do you think Nitin's patch is proof against this? Seems to me it's > probably got *more* failure cases, not fewer, if the system clock is > acting funny. You might be right. I sort of assumed that timeout.c had some defense against this, but since that seems not to be the case, I suppose no facility that depends on it can hope to stay out of trouble either. > On the whole, in these days of NTP, I'm not sure I care to spend > large amounts of effort on dealing with a bogus system clock. It's certainly less of an issue than it used to be back in my day. Any thoughts on the patch I attached? -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: