Re: Re: [COMMITTERS] pgsql: Start background writer during archive recovery.

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: Raw Message | Whole Thread | 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

In response to

Responses

Browse pgsql-committers by date

  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

Browse pgsql-hackers by date

  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