Re: Strange Windows problem, lock_timeout test request

Zoltan,

* Boszormenyi Zoltan (zb(at)cybertec(dot)at) wrote:
> Another question just popped up. Now, that
> bool enable_multiple_timeouts(List *timeouts);
> exists, do we really need the singular versions?
>
> Since the "timeout after N msec" have the per-lock and per-stmt
> versions, enable_timeout_after() gained a new argument to
> distinguish between the two cases and every occurrences of
> this function happen to just use "0" here. The only usage of the
> per-stmt variant is used with enable_multiple_timeouts().

For my 2c, I didn't partciularly care for changing
enable_timeout_after() by adding an extra parameter that ended up being
passed as ',0'.. Perhaps make it a wrapper instead of changing the
definition and leaving the invocations of it alone?

> Wouldn't it be better to have a single
> bool enable_timeouts(List *timeouts);
> instead?

This might also work though, if everything is updated to use it and it's
relatively clean. I realize for the aggregate case, you have to have
it, but I really don't like the changes to have to reset the counter
either.

Tom, can you comment on your thoughts around this notion of an aggregate
time constraint for waiting on locks? As mentioned upthread, I like the
idea of having an upper-limit on waiting for relation-level locks, but
once you're past that, I'm not sure that an aggregate waiting-on-locks
is any better than the overall statement-level timeout and it seems
somewhat messy, to me anyway.

Thanks,

Stephen