Zoltan, * Boszormenyi Zoltan (z...@cybertec.at) wrote: > attached is v30, I hope with everything fixed.
Making progress, certainly.
Given the hack to the API of enable_timeout_after() and the need for
timeout_reset_base_time(), I'm just going to voice my objection to the
"accumulated wait time on locks" portion again. I still like the idea
of a timeout for waiting on relation-level locks, as we acquire those
all up-front and we'd be able to just set a timeout at the appropriate
point and then release it when we're past acquiring the relation-level
locks. Seems like that would be much cleaner.
On the other hand, if we're going to go down this route, I'm really
starting to wonder if it should be the timeout systems responsibility to
keep track of such accumulated time.
Other than that..
> - List based enable/disable_multiple_timeouts()
That looks good, like the use of foreach(), etc, but I don't like how
you've set up delay_ms as a pointer..? Looks to be to allow you to
initialize the TimeoutParams structs early in proc.c..? Is there
another reason it needs to be a pointer that I'm missing? Why not build
the TimeoutParam strcutures in the if() blocks that check if the GUCs
are set..?
> - separate per-lock and per-statement lock_timeout variants
> - modified comments and documentation
Thanks.
Stephen
signature.asc
Description: Digital signature
