Re: Implementing setQueryTimeout() - round 2

Based on feedback so far here's attempt #2. The main thing I got out of
the feedback is that statement_timeout seems to be enough for most people.

Unfortunately statement_timeout is not sufficient for what I need, so my
changes will end up doing more than that. Here's an attempt at a compromise:

Add 4 new connection parameters, associated connection / statement
values and accessors on the postgresql extension interfaces:

- softQueryTimeout: 0=disabled, >0 = timeout in ms, default 0
- hardQueryTimeout: 0=disabled, >0 = timeout in ms, default 0
- softQueryMargin: -1=disabled, >=0 = margin in ms, default 0
- hardQueryMargin: -1=disabled, >=0 = margin in ms, default 60s

The soft query timeout (if enabled) makes the driver set
statement_timeout before executing a query, which in most cases will
result in a SQLException being reported if the timeout is reached (but
this is not guaranteed).

The hard query timeout (if enabled) makes the driver forcibly close the
connection after that timeout if the query has not completed, which will
result in a fatal SQLException due to an IOException from the blocked
query thread.

The setQueryTimeout(N) logic then looks something like this:

> if (N == 0) {
> softQueryTimeout = hardQueryTimeout = 0;
> return;
> }
>
> if (softQueryMargin == -1 && hardQueryMargin == -1)
> throw new PSQLException("not implemented");
>
> if (softQueryMargin != -1)
> softQueryTimeout = max(1,N*1000+softQueryMargin)
> else
> softQueryTimeout = 0;
>
> if (hardQueryMargin != -1)
> hardQueryTimeout = max(1,N*1000+hardQueryMargin)
> else
> hardQueryTimeout = 0;

The net effect is that if you call "setQueryTimeout(N)" by default you
get an attempt at query cancellation after N seconds and a hard close of
the connection after N+60 seconds.

Any comments on this iteration? Too configurable? Not configurable
enough? Are the defaults sensible?

-O