| From: | Greg Nancarrow <gregn4422(at)gmail(dot)com> | 
|---|---|
| To: | Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru> | 
| Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | Re: On login trigger: take three | 
| Date: | 2020-12-08 00:17:33 | 
| Message-ID: | CAJcOf-dgm544Or7HLqznkxAAyNjV3k4WUyrZVZSUU6YXtDL2Mw@mail.gmail.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
On Fri, Dec 4, 2020 at 9:05 PM Konstantin Knizhnik
<k(dot)knizhnik(at)postgrespro(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Korotkov | 2020-12-08 00:20:10 | Re: range_agg | 
| Previous Message | Alvaro Herrera | 2020-12-08 00:00:10 | Re: range_agg |