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

From Bruce Momjian
Subject Re: droped out precise time calculations in src/interfaces/libpq/fe-connect.c
Date
Msg-id 200210150338.g9F3ctl16626@candle.pha.pa.us
Whole thread Raw
In response to Re: droped out precise time calculations in src/interfaces/libpq/fe-connect.c  (Denis A Ustimenko <denis@oldham.ru>)
Responses Re: droped out precise time calculations in src/interfaces/libpq/fe-connect.c  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Denis A Ustimenko wrote:
> Tom, excuse me, I forget to copy previous posting to pgsql-hackers@postgresql.org.
> 
> On Mon, Oct 14, 2002 at 09:53:27AM -0400, Tom Lane wrote:
> > Denis A Ustimenko <denis@oldham.ru> writes:
> > > On Sun, Oct 13, 2002 at 10:59:40PM -0700, Joe Conway wrote:
> > >> 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).
> > 
> > > Actually we have the state machine in connectDBComplete() and the timeout is
> > > set for machine as the whole. Therefore if 1 second timeout is seted for the
> > > connectDBComplete() the timeout of particualr iteration of loop can be less
> > > then 1 second. 
> > 
> > However, the code's been restructured so that we don't need to keep
> > track of the exact time spent in any one iteration.  The error is only
> > on the overall delay.  I agree with Joe that it's not worth the effort
> > needed (in the Win32 case) to make the timeout accurate to < 1 sec.
> > 
> 
> Beware of almost 1 second posiible error. For example: connect_timeout == 1,
> we start at 0.999999 then finish_time == 1. If CPU is quite busy we will
> do only one iteration. I don't know is it enough to make connection?
> True timeout in this case == 0.000001

Good question.  What is going to happen is that select() is going to be
passed tv_sec = 1, and it is going to sleep for one second.  Now, if
select is interrupted, another time() call is going to be made.  If the
second ticked just before we run time(), we are going to think one
second has elapsed and return, so in the non-interrupt case, we are
going to be fine, but with select() interrupted, we are going to have
this problem.  Now, if we used gettimeofday(), we would be fine, but we
don't have that on Win32 and the ported version of that looks pretty
complicated.  Maybe we will go with what we have and see if anyone
complains.

One idea I am looking at is to pass a time_t into pqWaitTimeout, and do
that clock checking in there, and maybe I can do a gettimeofday() for
non-Win32 and a time() on Win32.

--  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 by date:

Previous
From: Denis A Ustimenko
Date:
Subject: Re: droped out precise time calculations in src/interfaces/libpq/fe-connect.c
Next
From: Jeff Davis
Date:
Subject: Re: [GENERAL] Postgres-based system to run .org registry?