SEO

#1 (**permalink**) 04-18-2008, 12:55 AM

Bruce Momjian <bruce@momjian.us> writes:
! /* WaitForSingleObjectEx() uses milliseconds */
> ! waittime = timerCommArea.value.it_value.tv_usec / 1000 + timerCommArea.value.it_value.tv_sec * 1000;

Seems like this probably ought to round up not down:

waittime = (timerCommArea.value.it_value.tv_usec + 999) / 1000 + timerCommArea.value.it_value.tv_sec * 1000;

Otherwise, an attempt to wait for 100 usec would convert to waittime 0,
which seems like a bad thing. In general the semantics of timed waits
are always supposed to be "you wait at least this long".

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

#2 (**permalink**) 04-18-2008, 12:55 AM

Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> ! /* WaitForSingleObjectEx() uses milliseconds */
> > ! waittime = timerCommArea.value.it_value.tv_usec / 1000 + timerCommArea.value.it_value.tv_sec * 1000;
>
> Seems like this probably ought to round up not down:
>
> waittime = (timerCommArea.value.it_value.tv_usec + 999) / 1000 + timerCommArea.value.it_value.tv_sec * 1000;
>
> Otherwise, an attempt to wait for 100 usec would convert to waittime 0,
> which seems like a bad thing. In general the semantics of timed waits
> are always supposed to be "you wait at least this long".

I thought about that, but because statement_timeout is in millis, and
not micros, we can't have a value that gets rounded down. I am
thinking a cleaner solution is to check for secs and if that is 0 and
microsecs < 1000, you set millis = 1.

Patch attached and applied to head and 8.1.X.

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

#3 (**permalink**) 04-18-2008, 12:55 AM

Bruce Momjian <bruce@momjian.us> writes:
> Tom Lane wrote:
>> Seems like this probably ought to round up not down:

> I thought about that, but because statement_timeout is in millis, and
> not micros, we can't have a value that gets rounded down. I am
> thinking a cleaner solution is to check for secs and if that is 0 and
> microsecs < 1000, you set millis = 1.

This is much uglier, probably slower, and fixes the problem only for
the zero case --- it is just as wrong to wait 1 msec when the caller
asked for 1.5 msec. And per your own observation, statement_timeout
is not the only source of the wait values, so this code must not
assume that the value is a multiple of 1msec.

Please do it the other way.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

#4 (**permalink**) 04-18-2008, 12:55 AM

OK, done.

---------------------------------------------------------------------------

Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > Tom Lane wrote:
> >> Seems like this probably ought to round up not down:
>
> > I thought about that, but because statement_timeout is in millis, and
> > not micros, we can't have a value that gets rounded down. I am
> > thinking a cleaner solution is to check for secs and if that is 0 and
> > microsecs < 1000, you set millis = 1.
>
> This is much uglier, probably slower, and fixes the problem only for
> the zero case --- it is just as wrong to wait 1 msec when the caller
> asked for 1.5 msec. And per your own observation, statement_timeout
> is not the only source of the wait values, so this code must not
> assume that the value is a multiple of 1msec.
>
> Please do it the other way.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

SEO

Re: [BUGS] BUG #2569: statement_timeout bug on Windows