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
