st 9. 12. 2020 v 13:17 odesÃlatel Greg Nancarrow <gregn4...@gmail.com> napsal:
> On Tue, Dec 8, 2020 at 3:26 PM Pavel Stehule <pavel.steh...@gmail.com> > wrote: > > > > > > 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 > > > PGC_SU_BACKEND is too strong, there should be PGC_BACKEND if this option can be used by database owner Pavel > I've created a separate patch to address question (1), rather than > include it in the main patch, which I've adjusted accordingly. I'll > leave question (2) until another time, as you suggest. > See the attached patches. > > Regards, > Greg Nancarrow > Fujitsu Australia >
