Re: On login trigger: take three

Поиск
Список
Период
Сортировка
От Greg Nancarrow
Тема Re: On login trigger: take three
Дата
Msg-id CAJcOf-eXTrMRttX=4tjJUtsXYpM_S_HPf3nV9OOAS9q-q9a-NQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: On login trigger: take three  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: On login trigger: take three  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: On login trigger: take three  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-hackers
On Tue, Dec 8, 2020 at 3:26 PM Pavel Stehule <pavel.stehule@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
checkedonly by the database owner or super user. It can be an alternative ALTER TABLE DISABLE TRIGGER ALL. It can be
protectionagainst necessity to restart to single mode to repair the event trigger. I think so more generic solution is
betterthan special disable_client_connection_trigger GUC. 
>
> 2. I have no objection against client_connection. It is probably better for the mentioned purpose - possibility to
blockconnection 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
bestarted also after the new statement "DISCARD SESSION", that will be started automatically after DISCARD ALL.  This
featureshould not be implemented in first step, but it can be a plan for support pooled connections 
>

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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Fujii Masao
Дата:
Сообщение: Re: Feature improvement for pg_stat_statements
Следующее
От: Dilip Kumar
Дата:
Сообщение: Re: Parallel INSERT (INTO ... SELECT ...)