Re: reaper should restart archiver even on standby - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: reaper should restart archiver even on standby
Date
Msg-id CAHGQGwEWLndi31FUqcdD00=h9b4VGnhLphUMj9jOjo6i_XyzZA@mail.gmail.com
Whole thread Raw
In response to Re: reaper should restart archiver even on standby  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: reaper should restart archiver even on standby  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On Wed, Jun 10, 2015 at 11:12 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> Fujii Masao wrote:
>> On Tue, Jun 9, 2015 at 5:21 AM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
>> > Fujii Masao wrote:
>
>> > Can't we create
>> > some common function that would be called both here and on ServerLoop?
>>
>> Agreed. So, what about the attached patch?
>
> No attachment ...

Ooops... Attached.

>> OTOH, in the other places where archiver is started up,
>> we can reach there during not only recovery but also normal processing.
>> So the conditions that we need to check are different.
>
> I think it would be simpler to centralize knowledge in a single
> function, and have that function take an argument indicating whether
> we're in recovery or normal processing, instead of spreading it to every
> place that can possibly start the archiver.

Agreed. The attached patch defines the macro to check whether archiver is
allowed to start up or not, and uses it everywhere except sigusr1_handler.
I made sigusr1_handler use a different condition because only it tries to
start archiver in PM_STARTUP postmaster state and it looks a bit messy
to add the check of that state into the centralized check condition.

Regards,

--
Fujii Masao

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: s_lock() seems too aggressive for machines with many sockets
Next
From: Alvaro Herrera
Date:
Subject: Re: Auto-vacuum is not running in 9.1.12