On Thu, Nov 30, 2017 at 9:34 AM, Alexander Voytsekhovskyy
<young.inbox@gmail.com> wrote:
> Thanks for helping, here is one more try
>
> #0 get_segment_by_index (area=area@entry=0x556026700be8, index=1) at
> /build/postgresql-10-qAeTPy/postgresql-10-10.1/build/../src/backend/utils/mmgr/dsa.c:1736
> #1 0x00005560252c2b90 in dsa_get_address (area=area@entry=0x556026700be8,
> dp=dp@entry=1099511685280) at
> /build/postgresql-10-qAeTPy/postgresql-10-10.1/build/../src/backend/utils/mmgr/dsa.c:945
> #2 0x00005560250a2c2b in tbm_attach_shared_iterate
> (dsa=dsa@entry=0x556026700be8, dp=1099511685280) at
> /build/postgresql-10-qAeTPy/postgresql-10-10.1/build/../src/backend/nodes/tidbitmap.c:1503
> #3 0x0000556025066c7b in BitmapHeapNext (node=node@entry=0x556026460710) at
> /build/postgresql-10-qAeTPy/postgresql-10-10.1/build/../src/backend/executor/nodeBitmapHeapscan.c:176
Thank you for the report and the back trace. I think this might be a
manifestation of the problem I just described[1] on -hackers.
Depending on the shape of a multi-Gather query plan and therefore the
order of control flow, you might finish up using the DSA area that
belongs to a different Gather node and then find that it goes away too
soon. Investigating.
https://www.postgresql.org/message-id/CAEepm%3D1U6as%3DbrnVvMNixEV2tpi8NuyQoTmO8Qef0-VV%2B%3D7MDA%40mail.gmail.com
--
Thomas Munro
http://www.enterprisedb.com
