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
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 |
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 |