On Wed, Oct 02, 2019 at 01:51:43PM -0400, Tom Lane wrote:
> Thus, we can't run any shutdown hooks before this one, if indeed we
> consider it to be a shutdown hook at all.
>
> A possible fix is to do it as the first action in proc_exit, but that will
> fall foul of Andres' points about not wanting to do it in non-session
> backends, nor in FATAL exits, nor in the case where a previous try failed.
> Perhaps a better idea is to put it into PostgresMain's handling of client
> EOF, despite the large comment saying not to add more code there.
Perhaps.
> (Or, maybe invent a new class of shutdown callbacks?
> before_before_shmem_exit seems like a pretty grotty concept, but it's
> more or less what we need here. It would sure be nice if we had an
> actual specification for what is allowed to happen in these different
> classes of callbacks...)
It seems to me that we may actually be looking at a concept of
callback priority here. Say you could assign a number to each
callback registered, and control their order at shutdown. I am
wondering if we shouldn't do that anyway. Likely there could be cases
where it makes sense to ensure the ordering of the actions where we
have dependencies between some subsystems? For example
ShutdownPostgres is registered first, meaning that it runs last
anyway. Now for other future things or even extensions there could be
an argument?
> In any case, the hook would have to be responsible for cancelling any open
> transaction for itself, in order to have a clean environment to run SQL
> code in. It cannot piggyback on existing transaction-closing code to do
> that, because any user-written code could throw an error inside the hook's
> transaction and thereby break the invariant that we're not in a
> transaction after that point.
Still, it would mean that any module hooking in the area would need to
do the cleanup all the time...
--
Michael
