Re: lock_timeout GUC patch
От | Boszormenyi Zoltan |
---|---|
Тема | Re: lock_timeout GUC patch |
Дата | |
Msg-id | 4B7F07BF.4020306@cybertec.at обсуждение исходный текст |
Ответ на | Re: lock_timeout GUC patch (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Hi, Tom Lane írta: > Boszormenyi Zoltan <zb@cybertec.at> writes: > >> You expressed stability concerns coming from this patch. >> Were these concerns because of locks timing out making >> things fragile or because of general feelings about introducing >> such a patch at the end of the release cycle? I was thinking >> about the former, hence this modification. >> > > Indeed, I am *very* concerned about the stability implications of this > patch. I just don't believe that arbitrarily restricting which > processes the GUC applies to will make it any safer. > > regards, tom lane > Okay, here is the rewritten lock_timeout GUC patch that uses setitimer() to set the timeout for lock timeout. I removed the GUC assignment/validation function. I left the current statement timeout vs deadlock timeout logic mostly intact in enable_sig_alarm(), because it's used by a few places. The only change is that statement_fin_time is always computed there because the newly introduced function (enable_sig_alarm_for_lock_timeout()) checks it to see whether the lock timeout triggers earlier then the deadlock timeout. As it was discussed before, this is 9.1 material. Best regards, Zoltán Böszörményi -- 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/
Вложения
В списке pgsql-hackers по дате отправления: