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
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, in
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
each
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
the
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 was
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 it surprising
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 get
