From: Tom Lane <tgl@sss.pgh.pa.us>
To: Rick Otten <rottenwindfish@gmail.com>
cc: pgsql-performance@lists.postgresql.org,
        Robert Haas <robertmhaas@gmail.com>,
        Thomas Munro <thomas.munro@enterprisedb.com>
Subject: Re: dsa_allocate() faliure
In-reply-to: 
 <CAMAYy4+w3NTBM5JLWFi8twhWK4=k_5L4nV5+bYDSPu8r4b97Zg@mail.gmail.com>
References: 
 <CAMAYy4+w3NTBM5JLWFi8twhWK4=k_5L4nV5+bYDSPu8r4b97Zg@mail.gmail.com>
Comments: In-reply-to Rick Otten <rottenwindfish@gmail.com>
	message dated "Mon, 29 Jan 2018 11:19:43 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4762.1517243829.1@sss.pgh.pa.us>
Date: Mon, 29 Jan 2018 11:37:09 -0500
Message-ID: <4763.1517243829@sss.pgh.pa.us>
Precedence: bulk

Rick Otten <rottenwindfish@gmail.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