Tom Lane wrote:
> Jessica Perry Hekman <jphekman@dynamicdiagrams.com> writes:
> > My other question was how to send the timeout value to the backend.
>
> I would imagine that the most convenient way to handle it would be as
> a SET variable:
>
> SET query_timeout = n;
>
> Establishes a time limit on subsequent queries (n expressed in
> milliseconds, perhaps).
>
> SET query_timeout = 0;
>
> Disables query time limit.
>
> This assumes that the query timeout should apply to each subsequent
> query, individually, until explicitly canceled. If you want a timeout
> that applies to only one query and is then forgotten, then maybe this
> wouldn't be the most convenient definition. What semantics are you
> trying to obtain, exactly?
Why don't we use two separate GUC variables and leave the BEGIN syntax as is completely?
SET transaction_timeout = m; SET statement_timeout = n;
The alarm is set to the smaller of (what's left for) the transaction or statement.
If you want to go sub-second, I suggest making it microseconds. That's what struct timeval (used
in struct itimerval) uses. But I strongly suggest not doing so at all, because the usage of itimers disables the
abilityto profile with gprof completely. Compute the time spent so far in a transaction exactly, but round UP
to full seconds for the alarm allways.
And before someone asks, no, I don't think that a connection_timeout is a good thing.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
