Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iBRDH-00053Q-EN for pgsql-hackers@arkaria.postgresql.org; Fri, 20 Sep 2019 22:17:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iBRDG-0004hW-0i for pgsql-hackers@arkaria.postgresql.org; Fri, 20 Sep 2019 22:17:14 +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_SHA1:256) (Exim 4.89) (envelope-from ) id 1iBRDF-0004hD-Oi for pgsql-hackers@lists.postgresql.org; Fri, 20 Sep 2019 22:17:13 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iBRDD-0003um-9K for pgsql-hackers@lists.postgresql.org; Fri, 20 Sep 2019 22:17:13 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id x8KMH2fW004219; Fri, 20 Sep 2019 18:17:02 -0400 From: Tom Lane To: Alvaro Herrera cc: Andres Freund , Andrew Dunstan , Kuntal Ghosh , Michael Paquier , Tomas Vondra , Robert Haas , Thomas Munro , PostgreSQL Hackers Subject: Re: subscriptionCheck failures on nightjar In-reply-to: <20190920220620.GA5214@alvherre.pgsql> References: <20190920220620.GA5214@alvherre.pgsql> Comments: In-reply-to Alvaro Herrera message dated "Fri, 20 Sep 2019 19:06:20 -0300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4217.1569017822.1@sss.pgh.pa.us> Date: Fri, 20 Sep 2019 18:17:02 -0400 Message-ID: <4218.1569017822@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Alvaro Herrera writes: > Uh .. I didn't think it was possible that we would build the same > snapshot file more than once. Isn't that a waste of time anyway? Maybe > we can fix the symptom by just not doing that in the first place? > I don't have a strategy to do that, but seems worth considering before > retiring the bf animals. The comment near the head of SnapBuildSerialize says * there is an obvious race condition here between the time we stat(2) the * file and us writing the file. But we rename the file into place * atomically and all files created need to contain the same data anyway, * so this is perfectly fine, although a bit of a resource waste. Locking * seems like pointless complication. which seems like a reasonable argument. Also, this is hardly the only place where we expect rename(2) to be atomic. So I tend to agree with Andres that we should consider OSes with such a bug to be unsupported. Dromedary is running the last release of macOS that supports 32-bit hardware, so if we decide to kick that to the curb, I'd either shut down the box or put some newer Linux or BSD variant on it. regards, tom lane