Re: droped out precise time calculations in src/interfaces/libpq/fe-connect.c

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: Denis A Ustimenko <denis(at)oldham(dot)ru>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: droped out precise time calculations in src/interfaces/libpq/fe-connect.c
Date: 2002-10-14 14:49:26
Message-ID: 200210141449.g9EEnQi07497@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-10-14 15:04:07 Re: Changing Column Order (Was Re: MySQL vs PostgreSQL.)
Previous Message Tom Lane 2002-10-14 14:49:05 Re: Let's get 7.3 done