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
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 time()
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 air
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
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
picked a
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 answer to
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 get
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 is odd;
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 if the
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 two seconds.
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 is odd;
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)
{
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 before,
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 2
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 remaining
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 so the
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?
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
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, the
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
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 about
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 now. I'm
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:
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
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 should be
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.
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
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
! *the
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 microseconds
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 were specifying
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?
True
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 enough to make
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
---(end
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
hence broke the
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 least not that I
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 =
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:
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
38 matches
Mail list logo
