Re: lock_timeout GUC patch

Boszormenyi Zoltan <zb@cybertec.at>

From: Boszormenyi Zoltan <zb@cybertec.at>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Greg Stark <stark@mit.edu>, pgsql-hackers@postgresql.org, Jaime Casanova <jcasanov@systemguards.com.ec>
Date: 2010-02-19T21:50:55Z
Lists: pgsql-hackers

Attachments

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/