Postgres Pro
Downloads
Home   >   mailing lists

Re: [BUGS] signal 11 segfaults with parallel workers - Mailing list pgsql-bugs

From Rick Otten
Subject Re: [BUGS] signal 11 segfaults with parallel workers
Date
Msg-id CAMAYy4JeYdX3vr+qsmbA9o66+wuSDyPTpsnPbkHNrZbRBYXHcA@mail.gmail.com
Whole thread Raw
In response to Re: [BUGS] signal 11 segfaults with parallel workers  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: [BUGS] signal 11 segfaults with parallel workers
List pgsql-bugs
Tree view
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.paquier@gmail.com> wrote:
On Mon, Jul 31, 2017 at 5:41 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Amit Kapila <amit.kapila16@gmail.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

pgsql-bugs by date:

Previous
From: Andres Freund
Date:
Subject: Re: [BUGS] BUG #14774: INSERT ... ON CONFLICT
Next
From: Andres Freund
Date:
Subject: [BUGS]