Re: 9.6, background worker processes, and PL/Java
От | Chapman Flack |
---|---|
Тема | Re: 9.6, background worker processes, and PL/Java |
Дата | |
Msg-id | 581156CF.6000707@anastigmatix.net обсуждение исходный текст |
Ответ на | Re: 9.6, background worker processes, and PL/Java (Craig Ringer <craig@2ndquadrant.com>) |
Ответы |
Re: 9.6, background worker processes, and PL/Java
(Craig Ringer <craig@2ndquadrant.com>)
|
Список | pgsql-hackers |
On 10/26/16 07:04, Amit Kapila wrote: > No, parallel workers in parallel query doesn't have MyProcPort. Ok ... it turns out I was using MyProcPort as a quick way to grab database_name and user_name (very early in startup, for a purpose analogous to setting a 'ps' process title), and that seemed more lightweight than other methods of getting the database and user Oids and mapping those to the corresponding names. But I guess I can change that easily enough. > ... >> Are BGWs for parallel queries born fresh for each query, or do they >> get pooled and reused? > > born fresh for each query. Yikes. But ok, if there's ever a reason to try to make a "safe" Java function, I see there is a parallel_setup_cost GUC that could be used to inform the planner of the higher cost when BGWs have to start JVMs, so it probably wouldn't make parallel plans often, but still could if analysis showed a sufficient advantage. On 10/26/16 07:15, Amit Kapila wrote: > All the GUCs are synchronised between leader and worker backends. Ah, thanks. I have now found README.parallel, so I much better understand what is synchronized, and what operations are allowed or not. :) On 10/26/16 07:42, Craig Ringer wrote: > > For loaded in shared_preload_libraries, test > > IsPostmasterEnvironment && !IsUnderPostmaster Hmm, IsUnderPostmaster is PGDLLIMPORTed but IsPostmasterEnvironment isn't, so I'm out of luck on Windows. Is there another way I can check? >> Do I detect I'm in a BGW by a non-null MyBgworkerEntry? > > Use IsBackgroundWorker, same place as above. Also not PGDLLIMPORTed. MyBgworkerEntry is, though. It does appear to be initialized to NULL. Can I get away with checking that, since I can't see IsBackgroundWorker? I now see what caused the reported crash. It was a parallel query that did not make any use of PL/Java functions, but the group leader had used them before so the library was loaded, so ParallelWorkerMain loaded it in the worker process, so _PG_init got called and was going to refer to stuff that wasn't set up yet, because the library loading comes pretty early in ParallelWorkerMain. I think I could easily fix that by having the library init code just bail right after defining the custom GUCs, if InitializingParallelWorker is true. Alas, InitializingParallelWorker isn't PGDLLIMPORTed either. This isn't my day. Is there a way I can successfully infer that on Windows? I guess I can just bail from initialization early when in *any* kind of background worker, and just leave the rest to be done when called through the language handler, if ever. This would be so much easier if Visual Studio were not a thing. -Chap
В списке pgsql-hackers по дате отправления: