RE: dsa_allocate() faliure

Поиск
Список
Период
Сортировка
От Arne Roland
Тема RE: dsa_allocate() faliure
Дата
Msg-id d0873916f481420c9af628a87809c905@index.de
обсуждение исходный текст
Ответ на Re: dsa_allocate() faliure  (Thomas Munro <thomas.munro@enterprisedb.com>)
Ответы Re: dsa_allocate() faliure  (Justin Pryzby <pryzby@telsasoft.com>)
Список 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
withevery 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
againwith 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
namedlike '%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
ParallelBitmap and inheritance/partitioned tables, but the error occurs relatively quickly in my case and every one of
myprocesses (the children and the master) are failing with 'FATAL:  dsa_allocate could not find 7 free pages'.
 

Regards
Arne




Вложения

В списке pgsql-performance по дате отправления:

Предыдущее
От: Bob Jolliffe
Дата:
Сообщение: Re: How can sort performance be so different
Следующее
От: Justin Pryzby
Дата:
Сообщение: Re: dsa_allocate() faliure