On Mon, Jul 31, 2017 at 8:26 AM, Andres Freund <andres@anarazel.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@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@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
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs