Horton
Menu

Re: subscriptionCheck failures on nightjar

Andres Freund <andres@anarazel.de>

View thread
From: Andres Freund <andres@anarazel.de>
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>
Date: 2019-09-20T22:11:22Z
Lists: pgsql-hackers 
Hi, 

On September 20, 2019 3:06:20 PM PDT, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
>On 2019-Sep-20, Tom Lane wrote:
>
>> Actually, what I did was as attached [1], and I am getting traces
>like
>> [2].  The problem seems to occur only when there are two or three
>> processes concurrently creating the same snapshot file.  It's not
>> obvious from the debug trace, but the snapshot file *does* exist
>> after the music stops.
>
>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.

We try to avoid it, but the check is racy. Check comments in SnapBuildSerialize. We could introduce locking etc to avoid that, but that seems overkill, given that were really just dealing with a broken os.

Andres
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix "base" snapshot handling in logical decoding