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  (Bruce Momjian <pgman@candle.pha.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?
        regards, tom lane


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

Предыдущее
От: Hannu Krosing
Дата:
Сообщение: Re: compiler warnings in ODBC
Следующее
От: "Tille, Andreas"
Дата:
Сообщение: Re: Serious performance problem