On Thu, Feb 1, 2018 at 8:48 AM, PG Bug reporting form
<noreply@postgresql.org> wrote:
> The following bug has been logged on the website:
>
> Bug reference: 15041
> Logged by: Daniel Farina
> Email address: daniel@fdr.io
> PostgreSQL version: 10.1
> Operating system: Linux
> Description:
>
> A database that was operating normally for quite a while suddenly generated
> three similar looking core-dumps near one another. The stack traces look
> like this.
>
> It is possible there was unusual memory pressure, at the time this occurred.
> This is the first occurrence.
>
> #0 alloc_object (size_class=<optimized out>, area=0x0) at dsa.c:1433
> #1 dsa_allocate_extended (area=0x0, size=size@entry=72,
> flags=flags@entry=4) at dsa.c:785
> #2 0x000000000062d277 in tbm_prepare_shared_iterate
> (tbm=tbm@entry=0x1e54160) at tidbitmap.c:807
> #3 0x00000000005f69a0 in BitmapHeapNext (node=node@entry=0x1d22a48) at
> nodeBitmapHeapscan.c:155
Hi Daniel,
Thanks for the report. This looks like the bug described here, where
"area" is a NULL pointer because we failed to launch a parallel query
(ie we're running a parallel query plan, but there are no workers and
no shared memory):
https://www.postgresql.org/message-id/CAEepm=0kADK5inNf_KuemjX=HQ=PuTP0DykM--fO5jS5ePVFEA@mail.gmail.com
It was fixed in commit c6755e233be1cccadd0884d952a2bb455fa0db1f and
back patched to REL_10_STABLE, so the fix will be in 10.2 (target 8th
Feb). The cause is running out of DSM slots, but not handing that
case correctly. I think this implies that you're running queries with
a lot of Gather [Merge] nodes in them? The number of DSM slots is 64 +
2 * max_connections, so one workaround is to crank up max_connections,
and another is just to disable parallelism for that query.
--
Thomas Munro
http://www.enterprisedb.com