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 05:48:41
Message-ID: 200210140548.g9E5mf826940@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Joe Conway wrote:
> Bruce Momjian wrote:
> > So, this is what needs to be dealt with to get it working.
> >
>
> More to the point, why is sub-second precision needed in this function?
> Connection timeout is given to us in whole seconds (1.205 code, i.e. prior to
> the patch in question):
>
> remains.tv_sec = atoi(conn->connect_timeout);
> if (!remains.tv_sec)
> {
> conn->status = CONNECTION_BAD;
> return 0;
> }
> remains.tv_usec = 0;
> rp = &remains;
>
> So there is no way to bail out prior to one second. Once you accept that the
> timeout is >= 1 second, and in whole second increments, why does it need
> sub-second resolution?

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. I would like to remove the tv_usec test because it suggests we
are doing something with microseconds when we are not. Also, should we
switch to a simple time() call, rather than gettimeofday()?

--
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 Anuradha Ratnaweera 2002-10-14 05:52:36 Re: Peer to peer replication of Postgresql databases
Previous Message Joe Conway 2002-10-14 05:15:52 Re: droped out precise time calculations in src/interfaces/libpq/fe-connect.c