If I do a "set max_parallel_workers_per_gather=0;" before I run the query
in that session, it runs just fine.
If I set it to 2, the query dies with the dsa_allocate error.
I'll use that as a work around until 10.2 comes out. Thanks! I have
something that will help.
On Mon, Jan 29, 2018 at 3:52 PM, Thomas Munro <thomas.mu...@enterprisedb.com
> On Tue, Jan 30, 2018 at 5:37 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> > Rick Otten <rottenwindf...@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
> >> 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
> > * succeed, since both get_best_segment and make_new_segment
> > * only return a non-NULL pointer if it actually contains enough
> > * contiguous freespace. If it does fail, something in our
> > * private state is out of whack, so use FATAL to kill the
> > */
> > 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.
> This is probably the bug fixed here:
> That was back patched, so 10.2 will contain the fix. The bug was not
> in dsa.c itself, but in the parallel query code that mixed up DSA
> areas, corrupting them. The problem comes up when the query plan has
> multiple Gather nodes (and a particular execution pattern) -- is that
> the case here, in the EXPLAIN output? That seems plausible given the
> description of a 50-branch UNION. The only workaround until 10.2
> would be to reduce max_parallel_workers_per_gather to 0 to prevent
> parallelism completely for this query.
> Thomas Munro