Re: [BUGS] signal 11 segfaults with parallel workers
От | Amit Kapila |
---|---|
Тема | Re: [BUGS] signal 11 segfaults with parallel workers |
Дата | |
Msg-id | CAA4eK1KH0wd3+tUDxMuMbqhLh0kKMu_TOfAcSVWuyfYVt9hfzQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [BUGS] signal 11 segfaults with parallel workers (Andres Freund <andres@anarazel.de>) |
Список | pgsql-bugs |
On Wed, Aug 9, 2017 at 1:27 AM, Andres Freund <andres@anarazel.de> wrote: > On 2017-08-08 21:55:50 +0200, Michael Paquier wrote: >> On Tue, Aug 8, 2017 at 9:51 PM, Andres Freund <andres@anarazel.de> wrote: >> > 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. >> >> Yeah, some prevention like that would be a good idea for module >> developers. > >> We could also check for a higher-level thing like being sure that >> there is no transaction context? > > Not quite sure what you mean by that? And if you just mean to ensure > that _PG_init() is called outside of a transaction - how? We load shared > libraries on demand when they're used - and that'll frequently be in a > transaction? > Yes. I was also thinking along those lines and don't you think we should better do RestoreLibraryState in a transaction in the parallel worker. Currently, we restore GUCState in a transaction and I think LibraryState can also be restored in a transaction (See ParallelWorkerMain). I have checked locally and it seems to be working. -- 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
В списке pgsql-bugs по дате отправления: