Re: Postgresql issue: FATAL: dsa_allocate could not find 7 free pages - Mailing list pgsql-general

From Thomas Munro
Subject Re: Postgresql issue: FATAL: dsa_allocate could not find 7 free pages
Date
Msg-id CAEepm=3QsnQw6nTUbvRoRYaxr2HpE8GDG7Uns02xj_-SX7pymw@mail.gmail.com
Whole thread Raw
In response to Postgresql issue: FATAL: dsa_allocate could not find 7 free pages  (Alexandre Assouad <alexandre.assouad@gmail.com>)
Responses Re: Postgresql issue: FATAL: dsa_allocate could not find 7 free pages
List pgsql-general
On Fri, Oct 26, 2018 at 2:21 AM Alexandre Assouad
<alexandre.assouad@gmail.com> wrote:
> FATAL:  dsa_allocate could not find 7 free pages

> Some users have faced this issue which seems to be a bug in postgresql query planner which should be solved :
> https://www.postgresql.org/message-id/CAEepm%3D1k7sYJbxoOSJcS-4ti2MHOnBXBfLf%3D-gtuFLTXPqvTDg%40mail.gmail.com

Hello Alexandre,

Thanks for the report.  Yes, that bug does seem like a plausible
explanation for that error.  The fix was in commit 8ffc3be1, which
will be included in 10.6 (target release date:  November 8th).  It's
also in 11.0, out now.

If you are able to reproduce the problem easily on a copy of your
database, and you have the time/inclination to investigate, is there
any chance you could test the query on a local build of REL_10_STABLE
(the branch that will produce 10.6 soon), instructions below, or the
released v11.0 (if Timescale is available for that, it doesn't look
like it)?  If not, no worries.

> But I’m still facing this issue.
> I’m using postgresql 10.5 on ubuntu 18.04
> With timescaledb extension (which could be involved in this bug but I couldn’t find any related issue on their side)

It's interesting that reports came from users of Citus and Timescale.
There doesn't seem to be any reason to think it's caused by anything
these extension are doing, other than just having a lot of data, big
queries and the right access pattern to hit that bug.

=== How to set up a throw-away REL_10_STABLE cluster:

On an Ubuntu developer machine, check out, build, install into
temporary directory:
sudo apt-get install git make gcc flex bison libz-dev libreadline-dev
git clone https://github.com/postgres/postgres.git
cd postgres
git checkout REL_10_STABLE
./configure --prefix=$HOME/tmp_install
make -s -j8 && make -s install

Initialise and start a database cluster:
~/tmp_install/bin/initdb -D ~/tmp_pgdata
~/tmp_install/bin/postgres -D ~/tmp_pgdata
... now postgres is running in the foreground, until you hit ^C
... do whatever you need to do to install Timescale extension, schema,
data, reproduce problem

To check that you can reproduce the problem in 10.5 with a server
built that way, stop that and:
git checkout REL_10_5
make -s clean && make -s -j8 && make -s install
~/tmp_install/bin/postgres -D ~/tmp_pgdata

To install Timescale it's probably the instructions from
https://github.com/timescale/timescaledb, using ./bootstrap
-DPG_CONFIG=~/tmp_install/bin/pgconfig but i haven't tried that
myself.

(You don't have to run initdb again or reload data when switching
between tags/branches in the 10.x series).

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


pgsql-general by date:

Previous
From: Christoph Moench-Tegeder
Date:
Subject: Re: rw_redis_fdw: SQL Errors when statement is within a function
Next
From: GPT
Date:
Subject: Re: rw_redis_fdw: SQL Errors when statement is within a function