Re: lock_timeout GUC patch

From: Boszormenyi Zoltan <zb(at)cybertec(dot)at>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org, Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>
Subject: Re: lock_timeout GUC patch
Date: 2010-02-19 21:50:55
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


Tom Lane írta:
> Boszormenyi Zoltan <zb(at)cybertec(dot)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

Attachment Content-Type Size
5-pg85-locktimeout-17-ctxdiff.patch text/x-patch 34.6 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-02-20 00:52:06 Re: Merge join and index scan strangeness
Previous Message Robert Haas 2010-02-19 21:48:22 Re: Fast or immediate shutdown