Re: pg_background (and more parallelism infrastructure patches) - Mailing list pgsql-hackers

From Andres Freund
Subject Re: pg_background (and more parallelism infrastructure patches)
Date
Msg-id 20141112171547.GC13473@awork2.anarazel.de
Whole thread Raw
In response to Re: pg_background (and more parallelism infrastructure patches)  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 2014-11-12 11:36:14 -0500, Robert Haas wrote:
> On Wed, Nov 12, 2014 at 11:19 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> > 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.
> 
> It looks like that does not work.
> 
> [rhaas pgsql]$ PGOPTIONS='-c local_preload_libraries=auto_explain' psql
> psql (9.5devel)
> Type "help" for help.
> 
> rhaas=# select * from pg_background_result(pg_background_launch('show
> auto_explain.log_min_duration')) as (x text);
> ERROR:  unrecognized configuration parameter "auto_explain.log_min_duration"
> CONTEXT:  background worker, pid 31316
> 
> So, there's more to be done here.  Rats.

We could just say having PGC_BACKEND guc's that aren't set to their
config files aren't supported for anything parallel. I find that a
reasonable thing - otherwise pooling of bgworkers and all that will
likely be out. And it's not that there are that many important
PGC_BACKEND gucs.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: recovery_target_time and standby_mode
Next
From: Jim Nasby
Date:
Subject: Re: Proposal: Log inability to lock pages during vacuum