Re: On login trigger: take three

Поиск
Список
Период
Сортировка
От Greg Nancarrow
Тема Re: On login trigger: take three
Дата
Msg-id CAJcOf-dgm544Or7HLqznkxAAyNjV3k4WUyrZVZSUU6YXtDL2Mw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: On login trigger: take three  (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>)
Ответы Re: On login trigger: take three  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-hackers
On Fri, Dec 4, 2020 at 9:05 PM Konstantin Knizhnik
<k.knizhnik@postgrespro.ru> wrote:
>
> As far as I understand Pavel concern was about the case when superuser
> defines wrong login trigger which prevents login to the system
> all user including himself. Right now solution of this problem is to
> include "options='-c disable_session_start_trigger=true'" in connection
> string.
> I do not know if it can be done with pgAdmin.
> >

As an event trigger is tied to a particular database, and a GUC is
global to the cluster, as long as there is one database in the cluster
for which an event trigger for the "client_connection" event is NOT
defined (say the default "postgres" maintenance database), then the
superuser can always connect to that database, issue "ALTER SYSTEM SET
disable_client_connection_trigger TO true" and reload the
configuration. I tested this with pgAdmin4 and it worked fine for me,
to allow login to a database for which login was previously prevented
due to a badly-defined logon trigger.

Pavel, is this an acceptable solution or do you still see problems
with this approach?


Regards,
Greg Nancarrow
Fujitsu Australia



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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: range_agg
Следующее
От: Alexander Korotkov
Дата:
Сообщение: Re: range_agg