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. -- With Regards, Amit Kapila.
