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 ...
|
Список | 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 по дате отправления: