Re: changing MyDatabaseId
От | Markus Wanner |
---|---|
Тема | Re: changing MyDatabaseId |
Дата | |
Msg-id | 4CE3DF07.5080909@bluegap.ch обсуждение исходный текст |
Ответ на | Re: changing MyDatabaseId (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: changing MyDatabaseId
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: