Re: dsa_allocate() faliure

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Rick Otten <rottenwindfish(at)gmail(dot)com>
Cc: pgsql-performance(at)lists(dot)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
Subject: Re: dsa_allocate() faliure
Date: 2018-01-29 16:37:09
Message-ID: 4763.1517243829@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

Rick Otten <rottenwindfish(at)gmail(dot)com> writes:
> I'm wondering if there is anything I can tune in my PG 10.1 database to
> avoid these errors:

> $ psql -f failing_query.sql
> psql:failing_query.sql:46: ERROR: dsa_allocate could not find 7 free pages
> CONTEXT: parallel worker

Hmm. There's only one place in the source code that emits that message
text:

/*
* Ask the free page manager for a run of pages. This should always
* succeed, since both get_best_segment and make_new_segment should
* only return a non-NULL pointer if it actually contains enough
* contiguous freespace. If it does fail, something in our backend
* private state is out of whack, so use FATAL to kill the process.
*/
if (!FreePageManagerGet(segment_map->fpm, npages, &first_page))
elog(FATAL,
"dsa_allocate could not find %zu free pages", npages);

Now maybe that comment is being unreasonably optimistic, but it sure
appears that this is supposed to be a can't-happen case, in which case
you've found a bug.

cc'ing the DSA authors for comment.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2018-01-29 16:44:22 Re: [HACKERS] MERGE SQL Statement for PG11
Previous Message Simon Riggs 2018-01-29 16:34:48 Re: [HACKERS] MERGE SQL Statement for PG11

Browse pgsql-performance by date

  From Date Subject
Next Message Thomas Munro 2018-01-29 20:52:43 Re: dsa_allocate() faliure
Previous Message Rick Otten 2018-01-29 16:19:43 dsa_allocate() faliure