Tom Lane írta: > Boszormenyi Zoltan <z...@cybertec.at> writes: > >> Tom Lane írta: >> >>> I think the way you're describing would be both harder to implement >>> and full of its own strange traps. >>> > > >> Why? >> > > Well, for one thing: if I roll back a subtransaction, should the lock > wait time it used now no longer count against the total?
Does statement_timeout counts against subtransactions as well? No. If a statement finishes before statement_timeout, does it also decrease the possible runtime for the next statement? No. I was talking about locks acquired during one statement. > If not, > once a timeout failure has occurred it'll no longer be possible for > the total transaction to do anything, even if it rolls back a failed > subtransaction. > > But more generally, what you are proposing seems largely duplicative > with statement_timeout. The only reason I can see for a > lock-wait-specific timeout is that you have a need to control the > length of a specific wait and *not* the overall time spent. Hans > already argued upthread why he wants a feature that doesn't act like > statement_timeout. > He argued about he wants a timeout *independent* from statement_timeout for locks only inside the same statement IIRC. > regards, tom lane > > -- Bible has answers for everything. Proof: "But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil." (Matthew 5:37) - basics of digital technology. "May your kingdom come" - superficial description of plate tectonics ---------------------------------- Zoltán Böszörményi Cybertec Schönig & Schönig GmbH 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
