Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Still, one could ask why we are expending extra cycles to make the
> >> timeout more accurate. Who the heck needs an accurate timeout on
> >> connect? Can you really give a use-case where the user won't have
> >
I will keep this in case we need it later. I think we worked around
this problem by having timeout == 1 set equal to 2 so we get at least
one second for the connection.
---
Denis A Ustimenko wrote:
> On Mon, Oct 14, 2002 a
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Still, one could ask why we are expending extra cycles to make the
>> timeout more accurate. Who the heck needs an accurate timeout on
>> connect? Can you really give a use-case where the user won't have
>> picked a number out of the
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Yes, the new code has _three_ time() calls, rather than the old code
> > that I think only had two. I was going to mention it but I figured
> > time() was a pretty light system call, sort of like getpid().
> > I needed the additional
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Yes, the new code has _three_ time() calls, rather than the old code
> > that I think only had two. I was going to mention it but I figured
> > time() was a pretty light system call, sort of like getpid().
> > I needed the additional
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Yes, the new code has _three_ time() calls, rather than the old code
> that I think only had two. I was going to mention it but I figured
> time() was a pretty light system call, sort of like getpid().
> I needed the additional time() calls so the compu
On Mon, Oct 14, 2002 at 01:00:07AM -0400, Bruce Momjian wrote:
> Denis A Ustimenko wrote:
> > On Sun, Oct 13, 2002 at 09:02:55PM -0700, Joe Conway wrote:
> > > Denis A Ustimenko wrote:
> > > >>Bruce, why have all precise time calculations been droped out in 1.206?
> > > >>If there is no
> > > >>g
Bruce Momjian wrote:
> Well, the fact you see a change of 0.0002 is significant. Let me add
> that in the old code there was only one time() call _in_ the loop, while
> now, there are two, so I can easily see there are several additional
> time() calls. Did you put your calls in the while loop?
Joe Conway wrote:
> Bruce Momjian wrote:
> > Yes, the new code has _three_ time() calls, rather than the old code
> > that I think only had two. I was going to mention it but I figured
> > time() was a pretty light system call, sort of like getpid().
> >
> > I needed the additional time() calls
Bruce Momjian wrote:
> Yes, the new code has _three_ time() calls, rather than the old code
> that I think only had two. I was going to mention it but I figured
> time() was a pretty light system call, sort of like getpid().
>
> I needed the additional time() calls so the computation of remainin
Joe Conway wrote:
> Seems to work well. But one slight concern:
>
> with previous 2 line patch
> --
> good connect info, using hostaddr, timeout = 1 || 2 second(s)
> =
> unsuccessful 0 times: avg n/a
> successful
Bruce Momjian wrote:
> Patch applied. I am applying it so it is in CVS and everyone can see
> it. I will keep modifying it until everyone likes it. It is just
> easier to do it that way when multiple people are reviewing it. They
> can jump in and make changes too.
I ran the same test as befo
Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
> > [ some convincing test cases that timeout=1 is not good ]
>
> > remains.tv_sec = atoi(conn->connect_timeout);
> > + if (remains.tv_sec == 1)
> > + remains.tv_sec += 1;
> > if (!remains
Joe Conway <[EMAIL PROTECTED]> writes:
> [ some convincing test cases that timeout=1 is not good ]
> remains.tv_sec = atoi(conn->connect_timeout);
> + if (remains.tv_sec == 1)
> + remains.tv_sec += 1;
> if (!remains.tv_sec)
>
Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
>
>> The thing was that with the extra +1, I was repeatedly getting a
>> wall-clock time of 2 seconds with a timeout set to 1 second. It seemed
>> odd to have my 1 second timeout automatically turned into 2 seconds every
>> time.
>
>
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> 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
Bruce Momjian <[EMAIL PROTECTED]> 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 i
Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
> > The thing was that with the extra +1, I was repeatedly getting a wall-clock
> > time of 2 seconds with a timeout set to 1 second. It seemed odd to have my 1
> > second timeout automatically turned into 2 seconds every time.
>
> That i
Joe Conway <[EMAIL PROTECTED]> writes:
> The thing was that with the extra +1, I was repeatedly getting a wall-clock
> time of 2 seconds with a timeout set to 1 second. It seemed odd to have my 1
> second timeout automatically turned into 2 seconds every time.
That is odd; seems like you should
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>>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.
>
> There is a very simple
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Denis A Ustimenko wrote:
> >> Beware of almost 1 second posiible error. For example: connect_timeout == 1,
> >> we start at 0.99 then finish_time == 1. If CPU is quite busy we will
> >> do only one iteration. I don't know is it en
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Denis A Ustimenko wrote:
>> Beware of almost 1 second posiible error. For example: connect_timeout == 1,
>> we start at 0.99 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?
>
Denis A Ustimenko wrote:
> Tom, excuse me, I forget to copy previous posting to [EMAIL PROTECTED]
>
> On Mon, Oct 14, 2002 at 09:53:27AM -0400, Tom Lane wrote:
> > Denis A Ustimenko <[EMAIL PROTECTED]> writes:
> > > On Sun, Oct 13, 2002 at 10:59:40PM -0700, Joe Conway wrote:
> > >> Well, if we we
Tom, excuse me, I forget to copy previous posting to [EMAIL PROTECTED]
On Mon, Oct 14, 2002 at 09:53:27AM -0400, Tom Lane wrote:
> Denis A Ustimenko <[EMAIL PROTECTED]> writes:
> > On Sun, Oct 13, 2002 at 10:59:40PM -0700, Joe Conway wrote:
> >> Well, if we were specifying the timeout in microsec
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > /*
> >* select() may modify timeout argument on some platforms so
> > ! *use copy.
> > ! *XXX Do we really want to do that? If select() returns
> > ! *
Bruce Momjian <[EMAIL PROTECTED]> writes:
> /*
>* select() may modify timeout argument on some platforms so
> ! *use copy.
> ! *XXX Do we really want to do that? If select() returns
> ! *the number of seconds rem
I have applied the following comment patch. The current code resets the
timer when select() is interruped. On OS's that modify timeout to show
the remaining time, we should be using that value instead of resetting
the timer to its original value on select retry.
---
Oops, overoptimized a little. ptmp_timeout is needed in case no time is
passed; ptmp_timeout restored.
---
pgman wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > That whole remains structure sho
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > That whole remains structure should be a time_t variable, and then we
> > _know_ we can't assume it is signed. The use of timeval should
> > happen only in pqWaitTimed because it has to use select().
>
> I think it's fine to use str
Bruce Momjian <[EMAIL PROTECTED]> writes:
> That whole remains structure should be a time_t variable, and then we
> _know_ we can't assume it is signed. The use of timeval should
> happen only in pqWaitTimed because it has to use select().
I think it's fine to use struct timeval as the parameter
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> 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?
>
> Yeah, the code could be simplified n
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> 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?
Yeah, the code could be simplified now. I'm also still not happy
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 sen
Denis A Ustimenko <[EMAIL PROTECTED]> 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, th
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 an
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. Bu
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):
>
>
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->c
Denis A Ustimenko wrote:
> On Sun, Oct 13, 2002 at 09:02:55PM -0700, Joe Conway wrote:
> > Denis A Ustimenko wrote:
> > >>Bruce, why have all precise time calculations been droped out in 1.206?
> > >>If there is no
> > >>gettimeofday in win32?
> >
> > gettimeofday was not portable to win32 (at l
On Sun, Oct 13, 2002 at 09:02:55PM -0700, Joe Conway wrote:
> Denis A Ustimenko wrote:
> >>Bruce, why have all precise time calculations been droped out in 1.206?
> >>If there is no
> >>gettimeofday in win32?
>
> gettimeofday was not portable to win32 (at least not that I could find) and
> henc
Denis A Ustimenko wrote:
>>Bruce, why have all precise time calculations been droped out in 1.206? If there is
>no
>>gettimeofday in win32?
gettimeofday was not portable to win32 (at least not that I could find) and
hence broke the win32 build of the clients.
Joe
---
41 matches
Mail list logo
