On 2014-11-12 11:15:26 -0500, Robert Haas wrote: > On Mon, Nov 10, 2014 at 4:58 PM, Andres Freund <and...@2ndquadrant.com> wrote: > > No, that's not what I was thinking of. Consider: > > > > export pg_libdir=$(pg_config --libdir) > > mkdir $pg_libdir/plugins > > ln -s $pg_libdir/auto_explain.so $pg_libdir/plugins/ > > PG_OPTIONS='-c local_preload_libraries=auto_explain' psql > > > > and use pg_background() (or something else using this infrastructure) in > > that context. > > Without having reread your relevant code I'd expect a: > > ERROR: 55P02: parameter "local_preload_libraries" cannot be set after > > connection start > > because the code would try to import the "user session's" > > local_preload_libraries values into the background process - after that > > actually already has done its initialization. > > Thanks for these pointers. Your directions turn out to be wrong in > detail, because it's PGOPTIONS not PG_OPTIONS, and the plugins > directory needs to be under $(pg_config --libdir)/postgresql, not just > $(pg_config --libdir). But it was enough to get me on the right > track. Long story short, it seems to work:
Sorry, was extracting it from a larger local script... > [rhaas ~]$ PGOPTIONS='-c local_preload_libraries=auto_explain' psql > psql (9.5devel) > Type "help" for help. > > rhaas=# show local_preload_libraries; > local_preload_libraries > ------------------------- > auto_explain > (1 row) > > rhaas=# select * from pg_background_result(pg_background_launch('show > local_preload_libraries')) as (x text); > x > -------------- > auto_explain > (1 row) The question is whether the library is actually loaded in that case? Because that normally only happens early during startup - which is why it's a PGC_BACKEND guc. > > How do you define 'SAFE' here? Safe against concurrent SQL level > > activity? Safe against receiving arbitrary data? > > The first one. The code powering the background worker is just as > trustworthy as any other part of the backend, so it can be subverted > if you load malicious C code into the backend, but not otherwise. Ah, good. Because the latter sounds quite hard, if not impossible lest we recreate send/recv ;) Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers