Horton

Re: dsa_allocate() faliure

Thomas Munro <thomas.munro@enterprisedb.com>

View thread View on postgr.es
From: Thomas Munro <thomas.munro@enterprisedb.com>
To: Jakub Glapa <jakub.glapa@gmail.com>
Cc: Justin Pryzby <pryzby@telsasoft.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>
Date: 2019-02-08T02:29:27Z
Lists: pgsql-hackers, pgsql-performance 
On Fri, Feb 8, 2019 at 4:49 AM Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> I don't have the answer yet but I have some progress: I finally
> reproduced the "could not find %d free pages" error by running lots of
> concurrent parallel queries.  Will investigate.

Sometimes FreeManagerPutInternal() returns a
number-of-contiguous-pages-created-by-this-insertion that is too large
by one.  If this happens to be a new max-number-of-contiguous-pages,
it causes trouble some arbitrary time later because the max is wrong
and this FPM cannot satisfy a request that large, and it may not be
recomputed for some time because the incorrect value prevents
recomputation.  Not sure yet if this is due to the lazy computation
logic or a plain old fence-post error in the btree consolidation code
or something else.

-- 
Thomas Munro
http://www.enterprisedb.com

Commits

  1. Fix rare dsa_allocate() failures due to freepage.c corruption.

  2. Release notes for 10.4, 9.6.9, 9.5.13, 9.4.18, 9.3.23.

  3. Fix crashes on plans with multiple Gather (Merge) nodes.