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. 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers