pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Justin Pryzby <pryzby@telsasoft.com>
To: Arne Roland <A.Roland@index.de>
Cc: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: 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: Fri, 1 Feb 2019 12:08:11 -0600
Message-ID: <20190201180811.GE29720@telsasoft.com> (raw)
In-Reply-To: <d0873916f481420c9af628a87809c905@index.de>
References: <CAMAYy4+w3NTBM5JLWFi8twhWK4=k_5L4nV5+bYDSPu8r4b97Zg@mail.gmail.com>
	<CAEepm=0p5nJDAjZoqa9ovdJC_sDwbhWcwBCkVS_iSEtXR9ZYYg@mail.gmail.com>
	<d0873916f481420c9af628a87809c905@index.de>

On Thu, Jan 31, 2019 at 06:19:54PM +0000, Arne Roland wrote:
> this is reproducible, while it's highly sensitive to the change of plans (i.e. the precise querys that do break change with every new analyze). Disabling parallel query seems to solve the problem (as expected).
> At some point even the simple query
> select count(*) from test_tab where (o = '0' and date >= '30.01.2019'::date-interval '14 days' or o = '1' and date >= '30.01.2019'::date-interval '14 days') and coalesce(fid,fallback) >=6 and coalesce(fid,fallback) <=6
> was reported to fail (with the same error) at the live database, but I wasn't able to obtain a plan, since it works again with the current live data (maybe autoanalyze is at fault here). 
> The table test_tab has roughly 70 children that inherit from it. The children and the corresponding indexes should be named like '%part%'.
> 
> I attached a query with a plan that fails on my test database.

Thanks - note that previously Thomas said:

On Mon, Dec 03, 2018 at 11:45:00AM +1300, Thomas Munro wrote:
> On Sat, Dec 1, 2018 at 9:46 AM Justin Pryzby <pryzby@telsasoft.com> wrote:
> >                         elog(FATAL,
> >                                  "dsa_allocate could not find %zu free pages", npages);
> > +                       abort()
> 
> If anyone can reproduce this problem with a debugger, it'd be
> interesting to see the output of dsa_dump(area), and
> FreePageManagerDump(segment_map->fpm).  This error condition means

Are you able to cause the error in a test/devel/non-production environment to
run under a debugger, or could you compile with "abort();" after that elog() to
save a corefile ?

Justin




view thread (60+ messages)  latest in thread

Message-ID: <20190201180811.GE29720@telsasoft.com>
Permalink:  ../20190201180811.GE29720@telsasoft.com/
Also on:    postgresql.org/message-id/20190201180811.GE29720@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, 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: <20190201180811.GE29720@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