On 11/17/2010 02:19 PM, Alvaro Herrera wrote:
> Well, the autovacuum mechanism involves a lot of back-and-forth between
> launcher and postmaster, which includes some signals, a fork() and
> backend initialization. The failure possibilities are endless.
>
> Fork failure communication is similarly brittle.
I certainly agree to that. However, a re-connecting mechanism wouldn't
allow us to get rid of the existing avworker startup infrastructure
entirely.
And for increased robustness, we'd require a less brittle re-connecting
mechanism. Given Robert's list, that doesn't seem trivial, either. (But
still doable, yes).
> Right now we have this "delay", if the process is not up and running in
> 60 seconds then we have to assume that "something" happened, and we no
> longer wait for it. If we knew the process was already there, we could
> leave it alone; we'd know it would get to its duty eventually.
You are assuming presence of pool here. Which is fine, it's just not
something that a re-connecting feature would solve per se. (Says he who
coded the bgworkers pool thingie).
Regards
Markus Wanner