Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nfEOi-0006Ud-JD for pgsql-hackers@arkaria.postgresql.org; Fri, 15 Apr 2022 05:21:32 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nfEOh-0004KA-40 for pgsql-hackers@arkaria.postgresql.org; Fri, 15 Apr 2022 05:21:31 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nfEOg-0004K1-LY for pgsql-hackers@lists.postgresql.org; Fri, 15 Apr 2022 05:21:30 +0000 Received: from mail-oi1-x235.google.com ([2607:f8b0:4864:20::235]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nfEOe-0001yF-B1 for pgsql-hackers@lists.postgresql.org; Fri, 15 Apr 2022 05:21:29 +0000 Received: by mail-oi1-x235.google.com with SMTP id r85so2369844oie.7 for ; Thu, 14 Apr 2022 22:21:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leadboat.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=f0NtxL+z6WiCiofdybExEL1mmyKv+oMRuT7UERAOQu8=; b=M77cNjXHGgAfIkagCyowfXEvWSucHytWBYWwrt7/8xAZorXx6U3wR6+15RyrwmkxWn C3sYty6aw1BmVw4ybH8xJZxOu1qejJ8Hqje5owcsecOTiShPKit9CAEo7wjOPZAL0mto ztuWErMVDIewBtnP+qO5YmEJNPMOUVaVRgaHw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=f0NtxL+z6WiCiofdybExEL1mmyKv+oMRuT7UERAOQu8=; b=IuevigXqJVvV/5G0TIVJZCfLXplTjG+HM0EaIlxIeyK8uOX190g5tzYfVTE2ErJPvb cfoexGQqtdhNPondTFdIgwuoQBPhCwKUggo3QneESyVy42BbOTRd0/PTa3tpJJ6XqkDR q3KiWlynMNkSDGidk48BV6LqknA8tiBKUX6XdFTi21muKCUTkoy7ECBgFosDgOhrQWkz Wi+KeFqE8bfkTK3xCo+GDu6ltVU2D6vjbPjTXBLupmyw4Jub2r6qr7pkGbZq0LqqaTxn WvrG+/XrmM03eSno1kmnw3gmHb9XtKVkwWd0lIOPH3Arhf8US0Y7Uhf0KmcGFzVJimLp pPGQ== X-Gm-Message-State: AOAM533O632XI9Pm7d1+YsWE6MTgkmUdmmGggA66Kp2kzfqSgi4fQrjp FQLVCJuuHeOrhUYOUHOPc+EmdA== X-Google-Smtp-Source: ABdhPJz4TLpKeGacQJGI4iCXOOKQifUdnpEJT4tq4GyskA31YRHS/8oPw3pvDBJNZv+0LGvB0DeMAg== X-Received: by 2002:a05:6808:e89:b0:2f7:34db:6915 with SMTP id k9-20020a0568080e8900b002f734db6915mr913240oil.284.1650000087719; Thu, 14 Apr 2022 22:21:27 -0700 (PDT) Received: from rfd.leadboat.com ([2600:1702:a20:5750::2e]) by smtp.gmail.com with ESMTPSA id v20-20020a056870e29400b000da4a0089c9sm1384977oad.27.2022.04.14.22.21.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Apr 2022 22:21:27 -0700 (PDT) Date: Thu, 14 Apr 2022 22:21:25 -0700 From: Noah Misch To: Andres Freund Cc: Tom Lane , Peter Geoghegan , David Rowley , PostgreSQL Hackers Subject: Re: Intermittent buildfarm failures on wrasse Message-ID: <20220415052125.GD862547@rfd.leadboat.com> References: <1521388.1649953580@sss.pgh.pa.us> <1547912.1649971995@sss.pgh.pa.us> <1553951.1649975018@sss.pgh.pa.us> <1570894.1649986347@sss.pgh.pa.us> <20220415015249.kfsqxujrf2bn2wz6@alap3.anarazel.de> <20220415024515.GA862547@rfd.leadboat.com> <20220415051205.6abhlilh6fnjgohr@alap3.anarazel.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220415051205.6abhlilh6fnjgohr@alap3.anarazel.de> User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Thu, Apr 14, 2022 at 10:12:05PM -0700, Andres Freund wrote: > On 2022-04-14 19:45:15 -0700, Noah Misch wrote: > > I suspect the failure is somehow impossible in "check". Yesterday, I cranked > > up the number of locales, so there are now a lot more installcheck. Before > > that, each farm run had one "check" and two "installcheck". Those days saw > > ten installcheck failures, zero check failures. > > I notice that the buildfarm appears to run initdb with syncing enabled > ("syncing data to disk ... ok" in the initdb steps). Whereas pg_regress > uses --no-sync. Yep. > I wonder if that's what makes the difference? Now that you reproduced > it, does it still reproduce with --no-sync added? It does; the last version of my script used "initdb -N ...". > Also worth noting that pg_regress doesn't go through pg_ctl... Hmmm.