* Boszormenyi Zoltan (zb@cybertec.at) wrote:
> But unlike statement_timeout,
> with lock_timeout_stmt the statement can still finish after this limit
> as it does useful work besides waiting for locks.
It's still entirely possible to get 99% done and then hit that last
tuple that you need a lock on and just tip over the lock_timeout_stmt
limit due to prior waiting and ending up wasting a bunch of work, hence
why I'm not entirely sure that this is that much better than
statement_timeout.
> Thinking about it a bit more, I start to agree with it.
> It's not likely that any new timeout sources will get added
> to proc.c that has anything to do with waiting across multiple locks.
> From this POV, this accumulated time can be done by proc.c itself.
> But this makes it necessary to reschedule the timer from the
> ProcSleep() loop so it increases the number of setitimer() calls.
> But with clever coding, the "it_interval" part of struct itimerval
> can be used to decrease the number of setitimer calls, so it may
> be balanced out.
We're not even going down this code path until we're already waiting on
a lock from someone, right? Not sure that we need to stress out too
much about calling setitimer().
> Another thought is that there is no need to have an extra function
> to set the start time for the timeouts. It can be folded into
> enable_timeout_after(), enable_timeout_at() and
> enable_multiple_timeouts() and it simplifies the API, too.
Right, back to how the API was originally, for the most part, no? :)
> Since setitimer() has microsecond resolution, I wonder whether
> the timeout.c code shouldn't accept that, too. Especially if we want
> to keep the per-statement accumulated version for the lock timeout.
> Then time to wait that can be represented using int32 would be
> about 35.8 minutes at most, we will need to use int64 if the maximum
> number of millisecs is to stay as INT_MAX, which I guess it should.
>
> Comments?
Wouldn't that impact statement_timeout also..? I can definitely see
someone wanting to set that at, say, an hour. If anything, I continue
to feel that going the *other* way makes more sense- keep everything at
millisecond and just floor() down to the ms when we're doing accounting
based on microsecond information. Sure, we might end up waiting a bit
(a very small bit..) longer than we were supposed to, but I hardly see
that as being a major complaint.
Thanks,
Stephen
