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/
