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