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 <pry...@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
