Re: reaper should restart archiver even on standby

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: reaper should restart archiver even on standby
Date: 2015-06-10 14:26:52
Message-ID: CAHGQGwEWLndi31FUqcdD00=h9b4VGnhLphUMj9jOjo6i_XyzZA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jun 10, 2015 at 11:12 PM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)com> wrote:
> Fujii Masao wrote:
>> On Tue, Jun 9, 2015 at 5:21 AM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)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 Content-Type Size
restart_archiver_on_standby_v2.patch text/x-patch 3.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2015-06-10 14:49:06 Re: Auto-vacuum is not running in 9.1.12
Previous Message Tom Lane 2015-06-10 14:25:32 Re: s_lock() seems too aggressive for machines with many sockets