2013-02-27 19:07 keltezéssel, Tom Lane írta:
Stephen Frost <sfr...@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/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
