On Thu, Jan 28, 2021 at 8:17 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Mon, Dec 28, 2020 at 5:46 PM Masahiko Sawada <sawada.m...@gmail.com> wrote: > > > > On Sat, Dec 26, 2020 at 4:04 PM Pavel Stehule <pavel.steh...@gmail.com> > > wrote: > > > > > > > > > > > > so 26. 12. 2020 v 8:00 odesÃlatel Pavel Stehule <pavel.steh...@gmail.com> > > > napsal: > > >> > > >> Hi > > >> > > >> > > >>> Thank you. > > >>> I have applied all your fixes in on_connect_event_trigger-12.patch. > > >>> > > >>> Concerning enable_client_connection_trigger GUC, I think that it is > > >>> really useful: it is the fastest and simplest way to disable login > > >>> triggers in case > > >>> of some problems with them (not only for superuser itself, but for all > > >>> users). Yes, it can be also done using "ALTER EVENT TRIGGER DISABLE". > > >>> But assume that you have a lot of databases with different login > > >>> policies enforced by on-login event triggers. And you want temporary > > >>> disable them all, for example for testing purposes. > > >>> In this case GUC is most convenient way to do it. > > >>> > > >> > > >> There was typo in patch > > >> > > >> diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml > > >> index f810789..8861f1b 100644 > > >> --- a/doc/src/sgml/config.sgml > > >> +++ b/doc/src/sgml/config.sgml > > >> @@ -1,4 +1,4 @@ > > >> -<!-- doc/src/sgml/config.sgml --> > > >> +\<!-- doc/src/sgml/config.sgml --> > > >> > > >> I have not any objections against functionality or design. I tested the > > >> performance, and there are no negative impacts when this feature is not > > >> used. There is significant overhead related to plpgsql runtime > > >> initialization, but when this trigger will be used, then probably some > > >> other PLpgSQL procedures and functions will be used too, and then this > > >> overhead can be ignored. > > >> > > >> * make without warnings > > >> * make check-world passed > > >> * doc build passed > > >> > > >> Possible ToDo: > > >> > > >> The documentation can contain a note so usage connect triggers in > > >> environments with short life sessions and very short fast queries > > >> without usage PLpgSQL functions or procedures can have negative impact > > >> on performance due overhead of initialization of PLpgSQL engine. > > >> > > >> I'll mark this patch as ready for committers > > > > > > > > > looks so this patch has not entry in commitfestapp 2021-01 > > > > > > > Yeah, please register this patch before the next CommitFest[1] starts, > > 2021-01-01 AoE[2]. > > > > Konstantin, did you register this patch in any CF? Even though the > reviewer seems to be happy with the patch, I am afraid that we might > lose track of this unless we register it. >
I see the CF entry (https://commitfest.postgresql.org/31/2900/) for this work. Sorry for the noise. -- With Regards, Amit Kapila.
