Re: 9.6, background worker processes, and PL/Java - Mailing list 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