Re: lock_timeout GUC patch

From: Boszormenyi Zoltan <zb(at)cybertec(dot)at>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-01-21 14:41:30
Message-ID: 4B58679A.3070402@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Robert Haas írta:
> 2010/1/21 Boszormenyi Zoltan <zb(at)cybertec(dot)at>:
>
>> Tom Lane írta:
>>
>>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>>
>>>> I think that it is a very bad idea to implement this feature in a way
>>>> that is not 100% portable.
>>>>
>>> Agreed, this is not acceptable. If there were no possible way to
>>> implement the feature portably, we *might* consider doing it like this.
>>> But I think more likely it'd get rejected anyway. When there is a
>>> clear path to a portable solution, it's definitely not going to fly
>>> to submit a nonportable one.
>>>
>> OK, I will implement it using setitimer().
>> It may not reach 8.5 though, when will this last Commitfest end?
>>
>
> The CommitFest ends 2/15, but that's not really the relevant metric.
> Patches will be marked Returned with Feedback if they are not updated
> within 4-5 days of the time they were last reviewed, or more
> aggressively as we get towards the end. Also, if a patch needs a
> major rewrite, it should be marked Returned with Feedback and
> resubmitted for this CommitFest. It sounds like this patch meets that
> criterion; in addition, Tom has expressed concerns that this might be
> something that should be committed early in the release cycle rather
> than at the very end.
>
> ...Robert
>

Thanks. So it means that this patch will considered for 9.1.

I would like a mini-review on the change I made in the latest
patch by introducing the validator function. Is it enough
to check for
(source == PGC_S_DEFAULT || source == PGC_S_SESSION)
to ensure only interactive sessions can get lock timeouts?
This way autovacuum, replication and any other internal
processes get proper behaviour, i.e. the setting from
postgresql.conf is ignored and locks don't timeout for them.
Which other PGC_S_* settings can or must be enabled?

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/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2010-01-21 14:44:36 Re: 8.5 vs. 9.0
Previous Message Robert Haas 2010-01-21 14:30:56 Re: attoptions