Re: On login trigger: take three - Mailing list pgsql-hackers

From Greg Nancarrow
Subject Re: On login trigger: take three
Date
Msg-id CAJcOf-dgm544Or7HLqznkxAAyNjV3k4WUyrZVZSUU6YXtDL2Mw@mail.gmail.com
Whole thread Raw
In response to Re: On login trigger: take three  (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>)
Responses Re: On login trigger: take three
List 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 by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: range_agg
Next
From: Alexander Korotkov
Date:
Subject: Re: range_agg