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 825.1004741792@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [COMMITTERS] pgsql/ oc/src/sgml/client-auth.sgml oc/src/sgm ...  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: [COMMITTERS] pgsql/ oc/src/sgml/client-auth.sgml oc/src/sgm ...  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: [COMMITTERS] pgsql/ oc/src/sgml/client-auth.sgml  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> Fix pg_pwd caching mechanism, which was broken by changes to fork
>> postmaster children before client auth step.  Postmaster now rereads
>> pg_pwd on receipt of SIGHUP, the same way that pg_hba.conf is handled.

> Tom, does a client do a kill() to its parent on password change?

Right, it's basically the same as the way we handle checkpoint and
SI-overrun signaling:
/* * Signal the postmaster to reload its password-file cache. */if (IsUnderPostmaster)    kill(getppid(), SIGHUP);

> If this is true, people can't depend on editing pg_hba.conf and having
> the change take affect _only_ when they sighup the postmaster.

True.  But recall that in all previous releases it's been completely
unsafe to edit pg_hba.conf in place, so I don't regard this as a big
step backwards.

We could possibly set up the password-file-reload action to occur on
some other, presently unused signal.  But there aren't a lot of spare
signal numbers left, and I'm not eager to use one up for this...
        regards, tom lane


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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: 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 ...