"Czichy, Thoralf (NSN - FI/Helsinki)" <thoralf.czi...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers