| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> | 
| Cc: | Simon Riggs <simon(at)2ndQuadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org | 
| Subject: | Re: Re: [COMMITTERS] pgsql: Start background writer during archive recovery. | 
| Date: | 2009-02-19 20:39:56 | 
| Message-ID: | 25555.1235075996@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-committers pgsql-hackers | 
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> Tom Lane wrote:
>> The thing wrong with it is assuming that nothing interesting will happen
>> during proc_exit().  We hang enough stuff on on_proc_exit hooks that
>> that seems like a pretty shaky assumption.
> I can't get too worried, given that proc_exit() is a very well-beaten 
> code path. Admittedly not so much for an auxiliary process, but that's 
> just a dumbed down version of what happens with a full-blown backend.
Well, you're assuming that no future patch or add-on module will put
anything into an on_proc_exit hook that might interact with other
processes.  It might be fine now but I don't think it's very robust.
> However I started looking into that idea anyway, and figured that it 
> does simplify the logic in postmaster.c quite a bit, so I think it's 
> worth doing on those grounds alone.
Couldn't you get rid of PMSIGNAL_RECOVERY_COMPLETED altogether?  If the
startup process exits with code 0, recovery is complete, else there
was trouble.  I find this SetPostmasterSignal bit quite ugly anyway.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2009-02-20 00:01:03 | pgsql: Simplify overcomplicated (and overly restrictive) test to see | 
| Previous Message | Tom Lane | 2009-02-19 20:32:45 | pgsql: Improve comments about semijoin implementation strategy, per a | 
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2009-02-19 20:44:59 | Re: Fixing Grittner's planner issues | 
| Previous Message | Peter Eisentraut | 2009-02-19 20:33:40 | Re: graph representation of data structures in optimizer |