From: Arne Roland <A.Roland@index.de>
To: Thomas Munro <thomas.munro@enterprisedb.com>
To: Sand Stone <sand.m.stone@gmail.com>
Cc: Rick Otten <rottenwindfish@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-performance@lists.postgresql.org <pgsql-performance@lists.postgresql.org>
Cc: Robert Haas <robertmhaas@gmail.com>
Subject: RE: dsa_allocate() faliure
Date: Thu, 24 Jan 2019 14:44:41 +0000
Message-ID: <6f3fe9fa5a984dc19e40e79fbef45edc@index.de> (raw)
In-Reply-To: <CAEepm=1k7sYJbxoOSJcS-4ti2MHOnBXBfLf=-gtuFLTXPqvTDg@mail.gmail.com>
References: <CAMAYy4+w3NTBM5JLWFi8twhWK4=k_5L4nV5+bYDSPu8r4b97Zg@mail.gmail.com>
<CAEepm=1k7sYJbxoOSJcS-4ti2MHOnBXBfLf=-gtuFLTXPqvTDg@mail.gmail.com>
Hello,
I'm not sure whether this is connected at all, but I'm facing the same error with a generated query on postgres 10.6.
It works with parallel query disabled and gives "dsa_allocate could not find 7 free pages" otherwise.
I've attached query and strace. The table is partitioned on (o, date). It's not depended on the precise lists I'm using, while it obviously does depend on the fact that the optimizer chooses a parallel query.
Regards
Arne Roland
-----Original Message-----
From: Thomas Munro <thomas.munro@enterprisedb.com>
Sent: Friday, October 5, 2018 4:17 AM
To: Sand Stone <sand.m.stone@gmail.com>
Cc: Rick Otten <rottenwindfish@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; pgsql-performance@lists.postgresql.org; Robert Haas <robertmhaas@gmail.com>
Subject: Re: dsa_allocate() faliure
On Wed, Aug 29, 2018 at 5:48 PM Sand Stone <sand.m.stone@gmail.com> wrote:
> I attached a query (and its query plan) that caused the crash: "dsa_allocate could not find 13 free pages" on one of the worker nodes. I anonymised the query text a bit. Interestingly, this time only one (same one) of the nodes is crashing. Since this is a production environment, I cannot get the stack trace. Once turned off parallel execution for this node. The whole query finished just fine. So the parallel query plan is from one of the nodes not crashed, hopefully the same plan would have been executed on the crashed node. In theory, every worker node has the same bits, and very similar data.
I wonder if this was a different symptom of the problem fixed here:
https://www.postgresql.org/message-id/flat/194c0706-c65b-7d81-ab32-2c248c3e2344%402ndquadrant.com
Can you still reproduce it on current master, REL_11_STABLE or REL_10_STABLE?
--
Thomas Munro
http://www.enterprisedb.comAttachments:
[application/octet-stream] strace.log (435.5K, ../6f3fe9fa5a984dc19e40e79fbef45edc@index.de/2-strace.log)
download
[application/octet-stream] query.sql (141.1K, ../6f3fe9fa5a984dc19e40e79fbef45edc@index.de/3-query.sql)
download
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: A.Roland@index.de, thomas.munro@enterprisedb.com, sand.m.stone@gmail.com, rottenwindfish@gmail.com, tgl@sss.pgh.pa.us, pgsql-performance@lists.postgresql.org, robertmhaas@gmail.com
Subject: RE: dsa_allocate() faliure
In-Reply-To: <6f3fe9fa5a984dc19e40e79fbef45edc@index.de>
* 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