From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Feature patch 1 for plperl [PATCH] |
Date: | 2010-01-11 00:05:47 |
Message-ID: | 4516.1263168347@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Dunstan <andrew(at)dunslane(dot)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
* erroring out 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 create PGC_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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2010-01-11 00:18:22 | Re: mailing list archiver chewing patches |
Previous Message | Tom Lane | 2010-01-10 23:57:44 | Re: We need to rethink relation cache entry rebuild |