Re: Feature patch 1 for plperl [PATCH] - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Feature patch 1 for plperl [PATCH]
Date
Msg-id 4516.1263168347@sss.pgh.pa.us
Whole thread Raw
In response to Re: Feature patch 1 for plperl [PATCH]  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> No, they have to all be PGC_POSTMASTER to answer that concern.  Only
>> breaking things for superusers isn't really that big an improvement
>> over breaking them for everybody.

> Well, I don't know about Tim but I think I could live with that. And 
> when we get some actual experience with using them we'll have a better 
> handle on whether or not it gives us any pain.

Upon further review, PGC_POSTMASTER isn't going to work because of this
in guc.c:
   /*    * Only allow custom PGC_POSTMASTER variables to be created during shared    * library preload; any later than
that,we can't ensure that the value    * doesn't change after startup.  This is a fatal elog if it happens; just    *
erroringout isn't safe because we don't know what the calling loadable    * module might already have hooked into.
*/  if (context == PGC_POSTMASTER &&       !process_shared_preload_libraries_in_progress)       elog(FATAL, "cannot
createPGC_POSTMASTER variables after startup");
 

We certainly don't want to make it such that plperl *has* to be
preloaded, so PGC_POSTMASTER is out.  However, I think PGC_SIGHUP
would be enough to address my basic worry, which is that people
shouldn't be depending on the ability to set these things within
an individual session.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: We need to rethink relation cache entry rebuild
Next
From: Alvaro Herrera
Date:
Subject: Re: mailing list archiver chewing patches