Re: signal 11 segfaults with parallel workers

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?

Regards,

Andres