Re: [COMMITTERS] pgsql/ oc/src/sgml/client-auth.sgml oc/src/sgm

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: [COMMITTERS] pgsql/ oc/src/sgml/client-auth.sgml oc/src/sgm
Дата
Msg-id 200111041800.fA4I0HF25071@candle.pha.pa.us
обсуждение исходный текст
Ответ на Re: [COMMITTERS] pgsql/ oc/src/sgml/client-auth.sgml oc/src/sgm ...  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [COMMITTERS] pgsql/ oc/src/sgml/client-auth.sgml oc/src/sgm ...  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> Peter Eisentraut <peter_e@gmx.net> writes:
> > But does this mean that postgresql.conf will be reread globally (i.e., by
> > the postmaster), when the user signals HUP only to a single backend?
> 
> No.  What it does mean is that ADD/DROP/ALTER USER will cause a global
> reread of the conf files.  That is kinda annoying, I agree.
> 
> We could avoid this by using a different signal number, but there's a
> shortage of available signals.  I was toying with the notion of unifying
> all three of the existing reasons for signalling the postmaster
> (SIGUSR1, SIGUSR2, SIGHUP) into a single child-to-parent signal number,
> say SIGUSR1.  A flag array in shared memory could be used to indicate
> what the reason(s) are for the most recent signal.  This would actually
> free up one signal number, which seems like a good idea in the long run.
> Comments?

While is not ideal, I am not too concerned that USER commands will
reread all config files.  Maybe we should wait to see if anyone reports
a problem with this behavior before adding code to correct it.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Beta going well
Следующее
От: Peter Harvey
Дата:
Сообщение: Re: compiler warnings in ODBC