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: Robert Haas <robertmhaas@gmail.com>
Cc: Jakub Glapa <jakub.glapa@gmail.com>, 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-09T20:24:53Z
Lists: pgsql-hackers, pgsql-performance 
On Sat, Feb 9, 2019 at 9:21 PM Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, Feb 8, 2019 at 8:00 AM Thomas Munro
> <thomas.munro@enterprisedb.com> wrote:
> > Sometimes FreeManagerPutInternal() returns a
> > number-of-contiguous-pages-created-by-this-insertion that is too large
> > by one. [...]
>
> I spent a long time thinking about this and starting at code this
> afternoon, but I didn't really come up with much of anything useful.
> It seems like a strange failure mode, because
> FreePageManagerPutInternal() normally just  returns its third argument
> unmodified. [...]

Bleugh.  Yeah.  What I said before wasn't quite right.  The value
returned by FreePageManagerPutInternal() is actually correct at the
moment it is returned, but it ceases to be correct immediately
afterwards if the following call to FreePageBtreeCleanup() happens to
reduce the size of that particular span.  The problem is that we
clobber fpm->contiguous_pages with the earlier (and by now incorrect)
value that we were holding in a local variable.

-- 
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.