From: | Markus Wanner <markus(at)bluegap(dot)ch> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: changing MyDatabaseId |
Date: | 2010-11-17 13:56:23 |
Message-ID: | 4CE3DF07.5080909@bluegap.ch |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Jaime Casanova | 2010-11-17 14:50:36 | Re: Review: rollback sequence reset for TRUNCATE ... RESTART IDENTITY |
Previous Message | Alvaro Herrera | 2010-11-17 13:39:49 | describe objects, as in pg_depend |