Tom Lane wrote:
> Jessica Perry Hekman <[EMAIL PROTECTED]> 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 ability to 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. #
#================================================== [EMAIL PROTECTED] #
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
