Date: Fri, 20 Sep 2019 15:11:22 -0700
User-Agent: K-9 Mail for Android
In-Reply-To: <20190920220620.GA5214@alvherre.pgsql>
References: <20190920220620.GA5214@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: subscriptionCheck failures on nightjar
To: Alvaro Herrera <alvherre@2ndquadrant.com>,Tom Lane <tgl@sss.pgh.pa.us>
CC: Andrew Dunstan <andrew@dunslane.net>,Kuntal Ghosh
 <kuntalghosh.2007@gmail.com>,Michael Paquier <michael@paquier.xyz>,Tomas
 Vondra <tomas.vondra@2ndquadrant.com>,Robert Haas
 <robertmhaas@gmail.com>,Thomas Munro
 <thomas.munro@enterprisedb.com>,PostgreSQL Hackers
 <pgsql-hackers@lists.postgresql.org>
From: Andres Freund <andres@anarazel.de>
Message-ID: <CE2CE820-8A48-4C0D-B06A-9BD3B1E26D43@anarazel.de>
Precedence: bulk

Hi,=20

On September 20, 2019 3:06:20 PM PDT, Alvaro Herrera <alvherre@2ndquadrant=
=2Ecom> wrote:
>On 2019-Sep-20, Tom Lane wrote:
>
>> Actually, what I did was as attached [1], and I am getting traces
>like
>> [2]=2E  The problem seems to occur only when there are two or three
>> processes concurrently creating the same snapshot file=2E  It's not
>> obvious from the debug trace, but the snapshot file *does* exist
>> after the music stops=2E
>
>Uh =2E=2E I didn't think it was possible that we would build the same
>snapshot file more than once=2E  Isn't that a waste of time anyway?=20
>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=2E

We try to avoid it, but the check is racy=2E Check comments in SnapBuildSe=
rialize=2E We could introduce locking etc to avoid that, but that seems ove=
rkill, given that were really just dealing with a broken os=2E

Andres
--=20
Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E