Date: Sun, 10 Feb 2019 18:02:15 -0600
From: Justin Pryzby <pryzby@telsasoft.com>
To: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Robert Haas <robertmhaas@gmail.com>,
	Jakub Glapa <jakub.glapa@gmail.com>,
	Fabio Isabettini <fisabettini@voipfuture.com>,
	Arne Roland <A.Roland@index.de>,
	Sand Stone <sand.m.stone@gmail.com>,
	Rick Otten <rottenwindfish@gmail.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: dsa_allocate() faliure
Message-ID: <20190211000215.GU31721@telsasoft.com>
References: 
 <CAJk1zg28tqx2021D0j-RqFtbLe+SPj4JKdmnc+K2aJZTUYk3eQ@mail.gmail.com>
 <20190206232110.GH29720@telsasoft.com>
 <CAJk1zg1aD9QieKBR0BzewDWFxbio+XakDFE7NcYzOk0JSm0tMg@mail.gmail.com>
 <CAEepm=1MvOE-Sfv1chudx5KEmw_qHYrj8F9Og_WmdBRhXSQ++w@mail.gmail.com>
 <CAEepm=2LOk6WgOcS31n0xJ9akgKP7E0gbYmbqz27D8vP6s1Rrw@mail.gmail.com>
 <CA+TgmoY=VEAMFoeRtP4j-ZOKM-B=4j671j5GKb3gYQ94-PgjhA@mail.gmail.com>
 <CAEepm=0m9PMTe3_+evvgOQPPxP1=hYNNoSdbE1o2FnqCqrFBwQ@mail.gmail.com>
 <CAEepm=2X8jDzJNj5UbnmdWcFfzRo6ZMpX2TAmApwzPc9thvo0w@mail.gmail.com>
 <CA+TgmoY4t7r9ac2vRnX1grL7yAaN9hJK6kG_8-D6ro8hNNjz-w@mail.gmail.com>
 <CAEepm=1C3t0B9yXDFtNgPDS0c--RZjDQuaCpFCaCaFUbPb6AFQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAEepm=1C3t0B9yXDFtNgPDS0c--RZjDQuaCpFCaCaFUbPb6AFQ@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Precedence: bulk

On Mon, Feb 11, 2019 at 09:45:07AM +1100, Thomas Munro wrote:
> Ouch.  Yeah, that'd do it and matches the evidence.  With this change,
> I couldn't reproduce the problem after 90 minutes with a test case
> that otherwise hits it within a couple of minutes.
...
> Note that this patch addresses the error "dsa_allocate could not find
> %zu free pages".  (The error "dsa_area could not attach to segment" is
> something else and apparently rarer.)

"could not attach" is the error reported early this morning while
stress-testing this patch with queued_alters queries in loops, so that's
consistent with your understanding.  And I guess it preceded getting stuck on
lock; although I don't how long between the first happened and the second, I'm
guess not long and perhaps immedidately; since the rest of the processes were
all stuck as in bug#15585 rather than ERRORing once every few minutes.

I mentioned that "could not attach to segment" occurs in leader either/or
parallel worker.  And most of the time causes an ERROR only, and doesn't wedge
all future parallel workers.  Maybe bug#15585 "wedged" state maybe only occurs
after some pattern of leader+worker failures (?)  I've just triggered bug#15585
again, but if there's a pattern, I don't see it.

Please let me know whether you're able to reproduce the "not attach" bug using
simultaneous loops around the queued_alters query; it's easy here.

Justin