Re: On login trigger: take three

út 8. 12. 2020 v 1:17 odesílatel Greg Nancarrow <gregn4422(at)gmail(dot)com>
napsal:

> 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.
>

yes, it can work .. Maybe for this operation only database owner rights
should be necessary. The super user is maybe too strong.

There are two maybe generic questions?

1. Maybe we can introduce more generic GUC for all event triggers like
disable_event_triggers? This GUC can be checked only by the database owner
or super user. It can be an alternative ALTER TABLE DISABLE TRIGGER ALL. It
can be protection against necessity to restart to single mode to repair the
event trigger. I think so more generic solution is better than special
disable_client_connection_trigger GUC.

2. I have no objection against client_connection. It is probably better for
the mentioned purpose - possibility to block connection to database. Can be
interesting, and I am not sure how much work it is to introduce the second
event - session_start. This event should be started after connecting - so
the exception there doesn't block connect, and should be started also after
the new statement "DISCARD SESSION", that will be started automatically
after DISCARD ALL. This feature should not be implemented in first step,
but it can be a plan for support pooled connections

Regards

Pavel

> Pavel, is this an acceptable solution or do you still see problems
> with this approach?
>
>
> Regards,
> Greg Nancarrow
> Fujitsu Australia
>