Re: signal 11 segfaults with parallel workers

On Mon, Jul 31, 2017 at 8:26 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> Hi,
>
> On 2017-07-30 21:05:50 -0400, Rick Otten wrote:
>> Ok, I got a core this time at 23:00 when the database went down.
>> Here is the basic backtrace:
>
>> (gdb) bt
>> #0 MemoryContextAlloc (context=0x0, size=size(at)entry=1024) at
>> /build/postgresql-9.6-5bnRDZ/postgresql-9.6-9.6.3/build/../src/backend/utils/mmgr/mcxt.c:761
>> #1 0x0000560b7a518ec4 in SPI_connect () at
>> /build/postgresql-9.6-5bnRDZ/postgresql-9.6-9.6.3/build/../src/backend/executor/spi.c:102
>> #2 0x00007fec467b9261 in _PG_init () from
>> /usr/lib/postgresql/9.6/lib/multicorn.so
>> #3 0x0000560b7a717cf2 in internal_load_library
>> (libname=libname(at)entry=0x7ff48208dbf8
>> <error: Cannot access memory at address 0x7ff48208dbf8>)
>> at
>> /build/postgresql-9.6-5bnRDZ/postgresql-9.6-9.6.3/build/../src/backend/utils/fmgr/dfmgr.c:276
>> #4 0x0000560b7a7188c0 in RestoreLibraryState (start_address=0x7ff48208dbf8
>> <error: Cannot access memory at address 0x7ff48208dbf8>)
>> at
>
> Rick: Looks like a buglet in multicorn, which seems to expect to be
> called in a valid memory context. Can you reproduce the bug if you use
> multicorn, and then in the same session execute the problematic query?
>
> Robert, was it intentional that we don't have a memory context defined
> at this point?
>

There is already a "Parallel Worker" memory context defined by that
time. I think the issue is that multicorn library expects that
Transaction context to be defined by that time.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com