On Wed, Oct 02, 2019 at 10:23:54AM -0700, Andres Freund wrote:
> - the startup hook isn't actually guaranteed to be able to write
> anything, we might be in hot-standby
Right.
> - 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 idea here is to have a hook which can be triggered at the start of
a process which can be externally triggered, which I guess is normal
even for WAL senders not connected to a database.
> - do we actually want to run code like this for e.g. FATAL errors?
That was the intention.
> - 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 */
We include in the backend code a dozen of hooks or so similar to this
one (excluding from the count GUC and reloption hooks and such). For
most of them we do not provide much extensive documentation nor
explanations similar to that, so it is rather unclear what would be a
minimum and acceptable set of comments and/or documentation which
would be fine (the same comment could basically apply to the planner
or post-parse hooks). Should we finally add a specific section in the
user-visible docs even if there has been reluctance to do so? My
guess is that we go down to this kind of requirement if we want to be
able to never forget to add documentation for any kind of new hook.
--
Michael
