RE: dsa_allocate() faliure

From: Arne Roland <A(dot)Roland(at)index(dot)de>
To: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
Cc: Sand Stone <sand(dot)m(dot)stone(at)gmail(dot)com>, Rick Otten <rottenwindfish(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-performance(at)lists(dot)postgresql(dot)org" <pgsql-performance(at)lists(dot)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: RE: dsa_allocate() faliure
Date: 2019-01-31 18:19:54
Message-ID: d0873916f481420c9af628a87809c905@index.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

Hi Thomas,

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.

I don't want to rule out the possibility that it could be related to #15585; at least both issues seem to be related to Parallel Bitmap and inheritance/partitioned tables, but the error occurs relatively quickly in my case and every one of my processes (the children and the master) are failing with 'FATAL: dsa_allocate could not find 7 free pages'.

Regards
Arne

Attachment Content-Type Size
explain1s.txt text/plain 1.4 MB
query1s.sql application/octet-stream 65.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2019-01-31 18:46:33 Re: Delay locking partitions during INSERT and UPDATE
Previous Message Robert Haas 2019-01-31 18:02:35 Re: ATTACH/DETACH PARTITION CONCURRENTLY

Browse pgsql-performance by date

  From Date Subject
Next Message Justin Pryzby 2019-02-01 18:08:11 Re: dsa_allocate() faliure
Previous Message Bob Jolliffe 2019-01-31 13:29:59 Re: How can sort performance be so different