Re: [COMMITTERS] pgsql/ oc/src/sgml/client-auth.sgml oc/src/sgm ...
От | Tom Lane |
---|---|
Тема | Re: [COMMITTERS] pgsql/ oc/src/sgml/client-auth.sgml oc/src/sgm ... |
Дата | |
Msg-id | 4207.1004890395@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql/ oc/src/sgml/client-auth.sgml (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
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? regards, tom lane
В списке pgsql-hackers по дате отправления: