Bcc:
Subject: Re: [BUGS] signal 11 segfaults with parallel workers
Reply-To:
In-Reply-To: <CAMAYy4JeYdX3vr+qsmbA9o66+wuSDyPTpsnPbkHNrZbRBYXHcA(at)mail(dot)gmail(dot)com>

Hi,

(please quote "properly" on pg lists, also don't trim the CC list wholesale)

On 2017-08-08 15:41:38 -0400, Rick Otten wrote:
> > > Whatever it's trying to initialize in _PG_init needs to be done later.
> >
> > Indeed, that's bad. I am adding in CC Ronan who has been working on
> > multicorn. At this stage, I think that you would be better out by
> > disabling parallelism.

> Just to follow up. The database has not crashed since I disabled
> parallelism. As a result of that change, some of my queries are running
> dramatically slower, I'm still working on doing what I can to get them back
> up to reasonable performance. I look forward to a solution that allows
> both FDW extensions and parallel queries to coexist in the same database.

This is going to need a multicorn bugfix. This isn't a postgres bug, and
other FDWs can coexist with parallelism. Therefore I unfortunately
think we can't really do anything here.

Perhaps, for v11, we should actually make sure there's no memory context
etc set during _PG_init() to catch such problems earlier? It's a bit
nasty to only see them if the shared library is preloaded and/or
parallelism is in use.

Greetings,

Andres Freund