"Czichy, Thoralf (NSN - FI/Helsinki)" <thoralf.czichy@nsn.com> writes:
> I am working together with Harald on this issue. Below some thoughts on
> why we think it should be possible to disable the postmaster-internal
> recovery attempt and instead have faults in the processes started
> by postmaster escalated to postmaster-exit.
I'll tell you what the fundamental problem with this is: it's converting
Postgres into a piece of software that is completely dependent on some
hypothetical outside management code in order to meet one of its basic
design goals. That isn't going to go over very well to start with.
Until you have written such management code, made it freely available,
and demonstrated that this type of recovery approach is *actually* not
hypothetically useful in a real-world environment, it's unlikely
that anyone is going to want to consider it.
I'd recommend just carrying a private patch to make Postgres do what
you want ... it's unlikely to be the only such patch you need anyway.
One obvious example is that nothing you describe is sensible without
exposing more information than "something failed" to the outside
management code. You'll want some kind of API in there to pass on
whatever the postmaster knows to the outside code.
We might consider adopting a set of patches like that once it's been
demonstrated to be useful for a live project, but I don't think we'll
accept it on speculation.
regards, tom lane