Re: lock_timeout GUC patch - Review
От
Boszormenyi Zoltan
Тема
Re: lock_timeout GUC patch - Review
Дата
Msg-id
4C56AB3C.20303@cybertec.at
Ответ на
Re: lock_timeout GUC patch - Review (Marc Cousin)
Список
Дерево обсуждения
Re: lock_timeout GUC patch - Review Marc Cousin <cousinmarc@gmail.com>
Re: lock_timeout GUC patch - Review Boszormenyi Zoltan <zb@cybertec.at>
Re: lock_timeout GUC patch - Review Alvaro Herrera <alvherre@commandprompt.com>
Re: lock_timeout GUC patch - Review Marc Cousin <cousinmarc@gmail.com>
Re: lock_timeout GUC patch - Review Boszormenyi Zoltan <zb@cybertec.at>
Re: lock_timeout GUC patch - Review Boszormenyi Zoltan <zb@cybertec.at>
Re: lock_timeout GUC patch - Review Marc Cousin <cousinmarc@gmail.com>
Re: lock_timeout GUC patch - Review "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
Re: lock_timeout GUC patch - Review Boszormenyi Zoltan <zb@cybertec.at>
Re: lock_timeout GUC patch - Review "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
Re: lock_timeout GUC patch - Review Robert Haas <robertmhaas@gmail.com>
Re: lock_timeout GUC patch - Review "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
Re: lock_timeout GUC patch - Review zb@cybertec.at
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
В списке pgsql-hackers по дате отправления