Re: logical replication launcher crash on buildfarm
От | Andres Freund |
---|---|
Тема | Re: logical replication launcher crash on buildfarm |
Дата | |
Msg-id | 20170401021928.47zjjryhty5kdzqz@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: logical replication launcher crash on buildfarm (Petr Jelinek <petr.jelinek@2ndquadrant.com>) |
Ответы |
Re: logical replication launcher crash on buildfarm
|
Список | pgsql-hackers |
On 2017-03-31 21:30:17 -0400, Robert Haas wrote: > On Fri, Mar 31, 2017 at 9:26 PM, Petr Jelinek > <petr.jelinek@2ndquadrant.com> wrote: > >> Hmm, I don't know if there's any good reason not to just use strcmp(), > >> but sure, OK. Committed and back-patched. > > > > Hmm culicidae still fails, this time only in parallel worker code. This > > didn't happen on my machine which is strange. Looking at the code, we > > are passing the fps->entrypoint as function pointer again so of course > > it fails. We have some code to load libraries again but even that gets > > initial entrypoint passed as function pointer > > (ParallelExtensionTrampoline). I wonder if we'll have to generalize the > > InternalBGWorkers even more to some kind of internal function name to > > pointer map and add the parallel entry points there as well. > > Argh, I forgot about that. I think we need to use something like > ParallelExtensionTrampoline all the time, not just for libraries. > Since effectively, we've determined that postgres itself has the same > problem. I wonder if we shouldn't just introduce a KnownFunctionPointer[] map, that can be used by various facilities (bgworkers themselves, parallelism, and probably more coming). Otherwise we'll introduce mechanisms like 7d8f6986b8 in multiple places. - Andres
В списке pgsql-hackers по дате отправления: