On Tue, Apr 4, 2017 at 2:08 PM, Petr Jelinek <petr.jeli...@2ndquadrant.com> wrote: > So this is what I came up with on plane. Generalized the loading > functionality into load_library_function which that can load either > known postgres functions or call load_external_function. > > I am not quite sure if fmgr.c is best place to put it, but I didn't want > to include stuff from executor in bgworker.c. I was thinking about > putting it to dfmgr.c (as that's where load_external_function) but again > seemed weird to including executor there. > > As with previous patch, 9.6 will need quite different patch as we need > to keep compatibility there, but since I am traveling I think it's > better to share what I have so far.
- * Register a new background worker while processing shared_preload_libraries. + * Register a new static background worker. * - * This can only be called in the _PG_init function of a module library - * that's loaded by shared_preload_libraries; otherwise it has no effect. + * This can only be called directly from postmaster or in the _PG_init + * function of a module library that's loaded by shared_preload_libraries; + * otherwise it will have no effect. This does seem to need updating, but that's a somewhat separate issue from fixing the problem at issue. + * Serialize extension entrypoint information. It's unsafe to pass + * function pointers across parallel processes as the function pointer + * may be different in new process in EXEC_BACKEND builds so we + * always pass library and function name. The word "extension" should be removed. This basically looks OK otherwise, but we'll need something else for 9.6. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
