2013-02-27 19:07 keltezéssel, Tom Lane írta:
> 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.
Perfect. :-)
> 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,
If we get rid of the per-statement variant, there is no need for that either.
> 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.
This way, enable_timeout_after() wouldn't have this extra argument either.
Thanks for your kind words.
Best regards,
Zoltán Böszörményi
--
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de http://www.postgresql.at/
