Re: lock_timeout GUC patch - Review

Поиск
Список
Период
Сортировка
От Boszormenyi Zoltan
Тема Re: lock_timeout GUC patch - Review
Дата
Msg-id 4C56B33F.2030108@cybertec.at
обсуждение исходный текст
Ответ на Re: lock_timeout GUC patch - Review  (Boszormenyi Zoltan <zb@cybertec.at>)
Ответы Re: lock_timeout GUC patch - Review  (Marc Cousin <cousinmarc@gmail.com>)
Список pgsql-hackers
Boszormenyi Zoltan írta:
> 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.

A little clarification is needed. The above statement is not entirely true.
There can be a case when all three timeout causes can be active, but only
when deadlock_timeout is the smallest of the three. If the fin_time value
for the another timeout cause is smaller than for deadlock_timeout then
there's no point to make deadlock_timeout active. And in case
deadlock_timeout
triggers and CheckDeadLock() finds that there really is a deadlock then the
possibly active lock_timeout gets disabled to avoid calling
RemoveFromWaitQueue() twice. I hope the comments in the code explain it
well.

>  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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Synchronous replication
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: Synchronous replication