Re: [HACKERS] [PATCH] A hook for session start

Поиск
Список
Период
Сортировка
От Yugo Nagata
Тема Re: [HACKERS] [PATCH] A hook for session start
Дата
Msg-id 20170721225851.5ae325ca.nagata@sraoss.co.jp
обсуждение исходный текст
Ответ на Re: [HACKERS] [PATCH] A hook for session start  (Fabrízio de Royes Mello <fabriziomello@gmail.com>)
Ответы Re: [HACKERS] [PATCH] A hook for session start  (Craig Ringer <craig@2ndquadrant.com>)
Re: [HACKERS] [PATCH] A hook for session start  (Fabrízio de Royes Mello <fabriziomello@gmail.com>)
Список pgsql-hackers
On Fri, 21 Jul 2017 10:31:57 -0300
Fabrízio de Royes Mello <fabriziomello@gmail.com> wrote:

> On Fri, Jul 21, 2017 at 9:35 AM, Yugo Nagata <nagata@sraoss.co.jp> wrote:
> >
> > On Fri, 21 Jul 2017 09:53:19 +0800
> > Craig Ringer <craig@2ndquadrant.com> wrote:
> >
> > > On 21 July 2017 at 08:42, Robert Haas <robertmhaas@gmail.com> wrote:
> > >
> > > > On Thu, Jul 20, 2017 at 8:27 AM, Fabrízio de Royes Mello
> > > > <fabriziomello@gmail.com> wrote:
> > > > > I'm not sure your real needs but doesn't it material for improve
> Event
> > > > > Triggers???
> > > >
> > > > I've thought about that, too.  One problem is what to do if the user
> > > > hits ^C while the event trigger procedure is running.  If you respond
> > > > to that by killing the event trigger and letting the user issue
> > > > commands, then the event trigger can't be used for security or
> > > > auditing purposes because the user might prevent it from doing
> > > > whatever it's intended to do with a well-timed interrupt.  If you
> > > > ignore ^C or make it turn into FATAL, then a poorly-crafted trigger
> > > > can lock users out of the database.  Maybe that's OK.  We could say
> > > > "well, if you lock yourself out of the database with your logon
> > > > trigger, you get to shut down the database and restart in single user
> > > > mode to recover".
> > > >
> > > > A hook, as proposed here, is a lot simpler and lacks these concerns.
> > > > Installing code in C into the database is intrinsically risky
> > > > anywhere, and not any moreso here than elsewhere.  But it's also less
> > > > accessible to the average user.
> > > > <http://www.postgresql.org/mailpref/pgsql-hackers>
> > >
> > >
> > > I'd favour the c hook personally. It's a lot more flexible, and can be
> used
> > > by an extension to implement trigger-like behaviour if anyone wants it,
> > > including the extension's choice of error handling decisions.
> > >
> > > It's also a lot simpler and less intrusive for core. Which is nice
> where we
> > > don't have something that we don't have anything compelling destined for
> > > core that needs it. (I want to add a bunch of hooks in the logical
> > > replication code in pg11 for similar reasons, and so features like DDL
> > > replication can be prototyped as extensions more practically).
> > >
>
> I agree with you both...
>
>
> > > That said, isn't ExecutorStart_hook + ProcessUtility_hook able to serve
> the
> > > same job as a session-start hook, albeit at slightly higher overhead?
> You
> > > can just test to see if your initial tasks have run yet.
> >
> > Thank you for your suggestion. Certainly, we can do the similar job of a
> > session-start hook using these existing hooks, although these hooks are
> > triggered when the first query is executed not when the session is
> started.
> > Now I come to think that an additional hook is not need.
> >
>
> As Nagata said hooks proposed by Craing will happens only when the first
> query is called so I don't know how it works for session start... are we
> missing something?

Yes, ExecutorStart_hook + ProcessUtility_hook is not strictly same as
session_start hook. If a query is issued a long time since the session start,
the timing the hook happens is largely deviated. It is no problem if we only
want do something once at the session start, but it might be problem if
we want to record the timestamp of the session start, for example.

>
> If we're going to add this hook what about add a session end hook also?

If someone want the session-start hook, he might want this too.

>
> Regards,
>
> --
> Fabrízio de Royes Mello
> Consultoria/Coaching PostgreSQL
> >> Timbira: http://www.timbira.com.br
> >> Blog: http://fabriziomello.github.io
> >> Linkedin: http://br.linkedin.com/in/fabriziomello
> >> Twitter: http://twitter.com/fabriziomello
> >> Github: http://github.com/fabriziomello


--
Yugo Nagata <nagata@sraoss.co.jp>



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] [COMMITTERS] pgsql: Add a Gather executor node.
Следующее
От: Hadi Moshayedi
Дата:
Сообщение: [HACKERS] [PATCH] Make ExplainBeginGroup()/ExplainEndGroup() public.