Re: Strange Windows problem, lock_timeout test request
От | Boszormenyi Zoltan |
---|---|
Тема | Re: Strange Windows problem, lock_timeout test request |
Дата | |
Msg-id | 512E52B4.6000307@cybertec.at обсуждение исходный текст |
Ответ на | Re: Strange Windows problem, lock_timeout test request (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Strange Windows problem, lock_timeout test request
|
Список | pgsql-hackers |
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/
В списке pgsql-hackers по дате отправления: