pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Justin Pryzby <pryzby@telsasoft.com>
To: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Jakub Glapa <jakub.glapa@gmail.com>
Cc: Fabio Isabettini <fisabettini@voipfuture.com>
Cc: Arne Roland <A.Roland@index.de>
Cc: Sand Stone <sand.m.stone@gmail.com>
Cc: Rick Otten <rottenwindfish@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: dsa_allocate() faliure
Date: Sun, 10 Feb 2019 18:02:15 -0600
Message-ID: <20190211000215.GU31721@telsasoft.com> (raw)
In-Reply-To: <CAEepm=1C3t0B9yXDFtNgPDS0c--RZjDQuaCpFCaCaFUbPb6AFQ@mail.gmail.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>

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




view thread (60+ messages)  latest in thread

Message-ID: <20190211000215.GU31721@telsasoft.com>
Permalink:  ../20190211000215.GU31721@telsasoft.com/
Also on:    postgresql.org/message-id/20190211000215.GU31721@telsasoft.com

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: pryzby@telsasoft.com, thomas.munro@enterprisedb.com, robertmhaas@gmail.com, jakub.glapa@gmail.com, fisabettini@voipfuture.com, A.Roland@index.de, sand.m.stone@gmail.com, rottenwindfish@gmail.com, pgsql-hackers@lists.postgresql.org
  Subject: Re: dsa_allocate() faliure
  In-Reply-To: <20190211000215.GU31721@telsasoft.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox