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 200210141449.g9EEnQi07497@candle.pha.pa.us
обсуждение исходный текст
Ответ на Re: droped out precise time calculations in src/interfaces/libpq/fe-connect.c  (Joe Conway <mail@joeconway.com>)
Ответы Re: droped out precise time calculations in src/interfaces/libpq/fe-connect.c  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Joe Conway wrote:
> Bruce Momjian wrote:
> > It could be argued that our seconds are not as exact as they could be
> > with subsecond timing.  Not sure it is worth it, but I can see the
> > point.
> 
> Well, if we were specifying the timeout in microseconds instead of seconds, it 
> would make sense to have better resolution. But when you can only specify the 
> timeout in seconds, the internal time comparison doesn't need to be any more 
> accurate than seconds (IMHO anyway).
> 
> > are doing something with microseconds when we are not.  Also, should we
> > switch to a simple time() call, rather than gettimeofday()?
> > 
> 
> Already done -- that's what Denis is unhappy about.

OK, I see that, but now, we are stuffing everything into a timeval
struct.  Does that make sense?  Shouldn't we just use time_t?  I realize
we need the timeval struct for select() in pqWaitTimed, but we are
making a copy of the timeval we pass in anyway. Seems it would be easier
just making it a time_t.

--  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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Let's get 7.3 done
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Changing Column Order (Was Re: MySQL vs PostgreSQL.)