Re: Hooks for session start and end, take two - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Hooks for session start and end, take two
Date
Msg-id 20191002172354.7mmij22e3fshqrf5@alap3.anarazel.de
Whole thread Raw
In response to Re: Hooks for session start and end, take two  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Hooks for session start and end, take two
Re: Hooks for session start and end, take two
List pgsql-hackers
Hi,

Moving the discussion of the issues leading to this being reverted back
to -hackers:

On 2019-10-02 23:52:31 +0900, Fujii Masao wrote:
> On Wed, Oct 2, 2019 at 10:08 PM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> >
> > On 2019-Oct-02, Michael Paquier wrote:
> >
> > > On Wed, Oct 02, 2019 at 01:27:50PM +0900, Fujii Masao wrote:
> > > > If only session end hook is problematic, you will commit session start
> > > > hook again?
> > >
> > > Sure, it would be possible to cut the apple in half here.  Now my
> > > understanding was that both hooks were a set.  What do people think?
> >
> > I think that having just session start is still useful

> +1

Well, I think the patch actually needs to do a lot more design work to
be comittable and usable. It's very unclear how these hooks are actually
supposed to be used safely.  Issues I see:

- the startup hook isn't actually guaranteed to be able to write
  anything, we might be in hot-standby
- the startup hook doesn't just run in normal sessions, it also runs in
  walsenders, including ones not connected to a database. But for some
  implementation reasons it won't run for background workers.
- the shutdown hook placement means that any error triggered within the
  handler probably cannot be cleaned up properly anymore
- do we actually want to run code like this for e.g. FATAL errors?
- THERE IS NOT A SINGLE COMMENT EXPLAINING WHAT CAN BE SAFELY DONE IN THESE
  HOOKS. In fact, outside of the tests, the only comments in this are:
  /* Hook for plugins to get control at start and end of session */
  /* Hook for plugins to get control at start of session */
  /* Hook at session end */
  /* Hook for plugins to get control at end of session */


> Regarding session end hook, you can do the almost same thing as that hook
> by calling on_shmem_exit(), before_shmem_exit() or on_proc_exit() in
> other hook like session start hook. This approach also has the same issue
> discussed upthread, though. Anyway, I'm not sure if session end hook is
> "actually" necessary.

No, it's not actually the same (at least for
before_shmem_exit). ShutdownPostgres() runs deliberately as the *last*
before_shmem_exit to run before we switch over to tearing down shmem:

    /*
     * Set up process-exit callback to do pre-shutdown cleanup.  This is the
     * first before_shmem_exit callback we register; thus, this will be the
     * last thing we do before low-level modules like the buffer manager begin
     * to close down.  We need to have this in place before we begin our first
     * transaction --- if we fail during the initialization transaction, as is
     * entirely possible, we need the AbortTransaction call to clean up.
     */

 *
 * User-level cleanup, such as temp-relation removal and UNLISTEN, happens
 * via separate callbacks that execute before this one.  We don't combine the
 * callbacks because we still want this one to happen if the user-level
 * cleanup fails.


- Andres



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: format of pg_upgrade loadable_libraries warning
Next
From: Alexey Kondratov
Date:
Subject: Re: Two pg_rewind patches (auto generate recovery conf and ensureclean shutdown)