Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fcUzU-0001l7-OM for buildfarm-members@arkaria.postgresql.org; Mon, 09 Jul 2018 12:10:05 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fcUzS-00046r-PO for buildfarm-members@arkaria.postgresql.org; Mon, 09 Jul 2018 12:10:02 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fcUzS-00046k-Js for buildfarm-members@lists.postgresql.org; Mon, 09 Jul 2018 12:10:02 +0000 Received: from yoda.llamalab.com ([194.14.207.58] helo=yoda.mksoft.nu) by magus.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1fcUzP-0000se-Qc for buildfarm-members@postgresql.org; Mon, 09 Jul 2018 12:10:01 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mksoft.nu; s=20151129; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=2DcpAMiRgoa2ZmMN5MUOIy0fiKODmtDuI2qdUSJ4nYA=; b=F30jWDZZMsRiBvTpzJyXj0gp07M8CNRoI1uGao5sXfu1kaSsOxRApWlsp/mvWjnoJpNMKkvCXvEJODEHJrj+GQvqy+1f4cEqGCJOAkt8VYhewTCIPZ3AqVWQ1y0gciFNkZTY6RmV5j8yMBY7+oefXZ5pFc2bPNlp0zdtkyOc8jkFUobPd2gVPqj4V5v6Z3A41sYtAoZEfCYwIgyIfS/cazBCnDILNC1FYu3c+nkf34Q6JcsTlL7HWlN1t9TW9JLuB14LGbrLSutcGSeAnJT3FBhU8dnxNOolLw4kI/H28SOgMHL4h3Cy2Y0CpMoNU+BO4SB+vJDJZ47FJteebFAo9Q==; Received: from c83-251-79-56.bredband.comhem.se ([83.251.79.56] helo=[10.100.0.2]) by yoda.mksoft.nu with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1fcUzM-00056Z-QS; Mon, 09 Jul 2018 14:09:57 +0200 Subject: Re: Reminder: spin up REL_11_STABLE on your buildfarm animals To: Andrew Dunstan , Tom Lane , buildfarm-members@postgresql.org References: <71293.1530992999@sss.pgh.pa.us> <5efff0db-b252-c974-a8f0-e7e0c3172f2c@2ndQuadrant.com> <400d7809-1084-d9bf-61f1-bd66d29d3393@2ndQuadrant.com> From: =?UTF-8?Q?Mikael_Kjellstr=c3=b6m?= Message-ID: Date: Mon, 9 Jul 2018 14:09:51 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 MIME-Version: 1.0 In-Reply-To: <400d7809-1084-d9bf-61f1-bd66d29d3393@2ndQuadrant.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: sv-SE Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2018-07-09 13:31, Andrew Dunstan wrote: > run_branches has a global lock that protects against concurrent runs of > different animals. You just point all the animals on the machine at the > same lock directory. I have several machines with this setup. See > global_lock_dir in the sample config file. Yes, that would work if the animals run in the same OS-instance/virtual machine. All my animals is running different OS (OpenBSD, FreeBSD, NetBSD, DragonFlyBSD etc.) and in different virtual machines. /Mikael