Re: signal 11 segfaults with parallel workers

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.

On Mon, Jul 31, 2017 at 3:52 AM, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
wrote:

> On Mon, Jul 31, 2017 at 5:41 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> writes:
> >> 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.
> >
> > It looks like multicorn supposes that a library's _PG_init function can
> > only be called inside a transaction. That is broken with a capital B.
> > We need not consider parallel query to find counterexamples: that
> > means you can't preload multicorn using shared_preload_libraries,
> > as that loads libraries into the postmaster, which never has and never
> > will run transactions.
> >
> > 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.
> --
> Michael
>