Re: logical replication launcher crash on buildfarm
От | Petr Jelinek |
---|---|
Тема | Re: logical replication launcher crash on buildfarm |
Дата | |
Msg-id | 59710cc4-0adf-e21b-cba6-1488c632e5b4@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: logical replication launcher crash on buildfarm (Petr Jelinek <petr.jelinek@2ndquadrant.com>) |
Список | pgsql-hackers |
On 01/04/17 04:19, Andres Freund wrote: > 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. > Yes that's what I meant with what I said above. -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: