Hi, Thank you, Konstantin, for this very good feature with numerous use cases. Please find the modified patch attached.
I’ve added the ‘enable_client_connection_trigger’ GUC to the sample config file and also an additional example page to the docs. Check world has passed and it is ready for committer. >Четверг, 28 января 2021, 12:04 +03:00 от Konstantin Knizhnik ><k.knizh...@postgrespro.ru>: > > > >On 28.01.2021 5:47, Amit Kapila 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. >> Yes, certainly: >https://commitfest.postgresql.org/31/2900/ > >-- >Konstantin Knizhnik >Postgres Professional: http://www.postgrespro.com >The Russian Postgres Company > >
on_connect_event_trigger-13a.patch
Description: Binary data
