Bruce Momjian <[EMAIL PROTECTED]> writes:
> Joe Conway wrote:
>> I can't think of a reason to have sub-second values, but it's
>> probably not worth changing it at this point.
> Most queries are sub-second in duration so it seemed logical to keep it
> the same as deadlock_timeout.
And machines g
Joe Conway wrote:
> Bruce Momjian wrote:
> > Uh, I thought you were changing connection_timeout, which is libpq and
> > not a GUC parameter
>
> Yup, you're right -- I got myself confused. Sorry.
>
> > not statement_timeout. Do we want sub-second
> > timeout values? Not sure.
> >
>
> I found
Bruce Momjian wrote:
> Uh, I thought you were changing connection_timeout, which is libpq and
> not a GUC parameter
Yup, you're right -- I got myself confused. Sorry.
> not statement_timeout. Do we want sub-second
> timeout values? Not sure.
>
I found it surprising that the statement_timeout
Joe Conway wrote:
> I was working with this approach, when I noticed on *unmodified* cvs tip
> (about a day old):
>
> test=# set statement_timeout=1;
> SET
> test=# \dt
> ERROR: Query was cancelled.
> test=#
>
> At:
>http://developer.postgresql.org/docs/postgres/runtime-config.html#LOGGING
Tom Lane wrote:
> It might work to measure time since the start of the whole process, or
> until the timeout target, rather than accumulating adjustments to the
> "remains" count each time through. In other words something like
>
> at start: targettime = time() + specified-timeout
>
>
Joe Conway <[EMAIL PROTECTED]> writes:
> ...it seems that the connection timeout can only be specified to the nearest
> second. Given that, is there any reason not to use time() instead of
> gettimeofday()?
As the code stands it's pretty necessary. Since we'll go around the
loop multiple times
I'm trying to get the client utilities to compile under win32/VS.net per
http://developer.postgresql.org/docs/postgres/install-win32.html.
I was able to do this successfully using the 7.2.2 tarball, but using current
7.3devel there are a number of minor issues (missing defines, adjustments to
