| From: | Boszormenyi Zoltan <zb(at)cybertec(dot)at> | 
|---|---|
| To: | Marc Cousin <cousinmarc(at)gmail(dot)com> | 
| Cc: | pgsql-hackers(at)postgresql(dot)org | 
| Subject: | Re: lock_timeout GUC patch - Review | 
| Date: | 2010-08-02 11:25:48 | 
| Message-ID: | 4C56AB3C.20303@cybertec.at | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
Marc Cousin írta:
> The Thursday 29 July 2010 13:55:38, Boszormenyi Zoltan wrote :
>   
>> I fixed this by adding CheckLockTimeout() function that works like
>> CheckStatementTimeout() and ensuring that the same start time is
>> used for both deadlock_timeout and lock_timeout if both are active.
>> The preference of errors if their timeout values are equal is:
>> statement_timeout > lock_timeout > deadlock_timeout
>>     
>
> As soon as lock_timeout is bigger than deadlock_timeout, it doesn't
> work, with this new version.
>
> Keeping the deadlock_timeout to 1s, when lock_timeout >= 1001, 
> lock_timeout doesn't trigger anymore.
>   
I missed one case when the lock_timeout_active should have been set
but the timer must not have been re-set, this caused the problem.
I blame the hot weather and having no air conditioning. The second is
now fixed. :-)
I also added one line in autovacuum.c to disable lock_timeout,
in case it's globally set in postgresq.conf as per Alvaro's comment.
Also, I made sure that only one or two timeout causes (one of
deadlock_timeout
and lock_timeout in the first case or statement_timeout plus one of the
other two)
can be active at a time. Previously I was able to trigger a segfault
with the default
1sec deadlock_timeout and lock_timeout = 999 or 1001. Effectively, the
system's
clock resolution makes the lock_timeout and deadlock_timeout equal and
RemoveFromWaitQueue() was called twice. This way it's a lot more robust.
Best regards,
Zoltán Böszörményi
| Attachment | Content-Type | Size | 
|---|---|---|
| 5-pg91-locktimeout-19-ctxdiff.patch | text/x-patch | 40.1 KB | 
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2010-08-02 11:32:05 | Re: Synchronous replication | 
| Previous Message | Fujii Masao | 2010-08-02 11:06:28 | Re: Synchronous replication |