| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Markus Wanner <markus(at)bluegap(dot)ch> |
| Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: changing MyDatabaseId |
| Date: | 2010-11-17 15:25:51 |
| Message-ID: | 26563.1290007551@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Markus Wanner <markus(at)bluegap(dot)ch> writes:
> 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.
I'm afraid that any such change would trade a visible, safe failure
mechanism (no avworker) for invisible, impossible-to-debug data
corruption scenarios (due to failure to reset some bit of cached state).
It certainly won't give me any warm fuzzy feeling that I can trust
autovacuum.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ross J. Reedstrom | 2010-11-17 15:32:53 | Re: contrib: auth_delay module |
| Previous Message | Tom Lane | 2010-11-17 15:20:06 | Re: describe objects, as in pg_depend |