Re: Feature patch 1 for plperl [PATCH]

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Feature patch 1 for plperl [PATCH]
Дата
Msg-id 4516.1263168347@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Feature patch 1 for plperl [PATCH]  (Andrew Dunstan <andrew@dunslane.net>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: We need to rethink relation cache entry rebuild
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: mailing list archiver chewing patches