David Christensen wrote:
> What are the semantics? If you launch a process and it crashes, is
> the postmaster responsible for relaunching it? Is there any
> additional monitoring of that process it would be expected to do?
> What defined hooks/events would you want to launch these processes
> from? If you have to kill a backend postmaster, do the auxiliary
> processes get killed as well, and with what signal? Are they killed
> when you stop the postmaster, and are they guaranteed to have
> stopped at this point? Can failing to stop prevent/delay the
> shutdown/restart of the server? Etc.
I think most of these should be defined by the called process, i.e.
there needs to be a way to pass flags to postmaster. For example, some
processes will need to cause a full postmaster restart, while most will
not. For those that do, we need some robustness check; for example we
could require that they participate in the PMChildSlot mechanism.
Regarding hooks or events, I think postmaster should be kept simple:
launch at start, reset at crash recovery, kill at stop. Salt and pepper
allowed but that's about it -- more complex ingredients are out of the
question due to added code to postmaster, which we want to be as robust
as possible and thus not able to cook much of anything else.
Now, if you run a postmaster with such a thing attached, you get no
support here on crash reports unless you can prove the crash can be
reproduced with it turned off (i.e. taint mode).
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support