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

On Fri, Jul 21, 2017 at 12:19 PM, Fabrízio de Royes Mello <fabriziomello@gmail.com> wrote:
>
>
> On Fri, Jul 21, 2017 at 10:58 AM, Yugo Nagata <nagata@sraoss.co.jp> wrote:
> >
> > 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.
> >
>
> Well if someone wants here are the patches... I just did a minor fix and cleanup in your previous session_start sample and provide both samples into the same patch.
>

I made a mistake on previous patch... now the attached three patches in their correct orders.

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