Re: timeout implementation issues

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