Re: Feature patch 1 for plperl [PATCH]

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

In response to

Browse pgsql-hackers by date

  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