<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">Roman, </div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">According to documentation [1] this setting is responsible for the amount of time to wait a lock to be released before trying to check if it is, in fact, a deadlock. This time just allows not to spend resources for unnecessary checks. </div><div class="gmail_default" style="font-family:monospace,monospace">If a lock is not a deadlock, this check will just skip it and request will continue to wait for a lock to be released until lock_timeout is exceeded. <br></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">[1] <a href="http://www.postgresql.org/docs/9.3/static/runtime-config-locks.html">http://www.postgresql.org/docs/9.3/static/runtime-config-locks.html</a><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div>Vladimir Kozhukalov</div></div></div>
<br><div class="gmail_quote">On Mon, Mar 21, 2016 at 7:39 PM, Roman Prykhodchenko <span dir="ltr"><<a href="mailto:me@romcheg.me" target="_blank">me@romcheg.me</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Folks,<br>
<br>
We have been analyzing a bunch of random failures in Fuel tests and encountered several ones caused by detector raising errors occasionally [1]. After attempts to reproduce the same behavior have failed we’ve decided to run the same test suit on overloaded nodes. Those test-runs allowed us to catch the same behavior we’ve seen on CI slaves. After analyzing both PostgreSQL logs and Nailgun’s code we’ve found no reasons for those deadlocks to occur.<br>
<br>
Thinking about the facts mentioned we came up with the idea that those random deadlocks occur in cases when CI slaves are overloaded by other jobs and transactions start hitting deadlock timeout. Thus I propose to change PostgreSQL’s deadlock_timeout value from the default one to 3-5 seconds. That will slow down tests, if they run on an overloaded CI slave but will help to avoid random and false-positive deadlock warnings.<br>
<br>
<br>
References:<br>
<br>
1. <a href="https://bugs.launchpad.net/fuel/+bug/1556070" rel="noreferrer" target="_blank">https://bugs.launchpad.net/fuel/+bug/1556070</a><br>
<br>
<br>
- romcheg<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div>