Stephen Frost <sfrost@snowman.net> writes:
> 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.
I think anything that makes this patch simpler is a good idea. I don't
like any of the accum_time stuff: it complicates the timeout API
unreasonably and slows down existing use cases.
Some other thoughts:
* timeout_reset_base_time() seems like an ugly and unnecessary API wart.
I don't like the timeout_start state variable at all; if you need
several timeouts to be scheduled relative to the exact same starting
point, can't you just do that in a single enable_multiple_timeouts()
call? And I think the optional TMPARAM_ACCUM action is completely
unacceptable, because it supposes that every user of a timeout, now and
in the future, is okay with having their accumulated time reset at the
same point. The whole point of having invented this timeout API is to
serve timeout uses we don't currently foresee, so actions that affect
every timeout seem pretty undesirable.
* I don't care for changing the API of enable_timeout_after when there
is in fact not a single caller using the flags argument (probably
because the only defined flag is too baroque to be useful). If there
were a use case for the "accum" action it'd be better to have a separate
API function for it, probably.
regards, tom lane
