Horton
Menu

Re: subscriptionCheck failures on nightjar

Alvaro Herrera <alvherre@2ndquadrant.com>

View thread
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>, 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:06:20Z
Lists: pgsql-hackers 
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.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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