Re: droped out precise time calculations in src/interfaces/libpq/fe-connect.c
От | Bruce Momjian |
---|---|
Тема | Re: droped out precise time calculations in src/interfaces/libpq/fe-connect.c |
Дата | |
Msg-id | 200210152142.g9FLg4915445@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: droped out precise time calculations in src/interfaces/libpq/fe-connect.c (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Tom Lane wrote: > >> That is odd; seems like you should get between 1 and 2 seconds. How > >> were you measuring the delay, exactly? > > > Remember, that if you add 1, the select() is going to get tv_sec = 2, so > > yes, it will be two seconds. > > Yeah, but only if the value isn't recalculated shortly later. Consider > > caller computes finish_time = time() + timeout; > > ... > > inside select-wait loop, compute max_delay = finish_time - time(); > > If the time() value has incremented by 1 second between these two lines > of code, you have a problem with a 1-second timeout... Yep. If you track finish time, you get that 1 second rounding problem, and if you track just duration/timeout, you get into the problem of not knowing when the timeout has ended. I don't think these can be fixed except by overestimating (+1) or by tracking subseconds along with seconds so you really know when one second has elapsed. Perhaps we need to modify a timeout of 1 to be 2 and leave other values alone. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
В списке pgsql-hackers по дате отправления: