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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers