Re: WAL Restore process during recovery

On Tue, Jan 24, 2012 at 9:43 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> On Tue, Jan 24, 2012 at 12:23 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> On Mon, Jan 23, 2012 at 12:23 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>>> Why does walrestore need to be invoked even when restore_command is
>>> not specified? It seems to be useless. We invoke walreceiver only when
>>> primary_conninfo is specified now. Similarly we should invoke walrestore
>>> only when restore_command is specified?
>>
>> walreceiver is shutdown and restarted in case of failed connection.
>> That never happens with walrestore because the command is run each
>> time - when we issue system(3) a new process is forked to run the
>> command. So there is no specific cleanup to perform and so no reason
>> for a managed cleanup process.
>>
>> So I can't see a specific reason to change that. Do you think it makes
>> a difference?
>
> Yes. When restore_command is not specified in recovery.conf, walrestore
> process doesn't do any useful activity and just wastes CPU cycle. Which
> might be harmless for a functionality of recovery, but ISTM it's better not
> to start up walrestore in that case to avoid the waste of cycle.

It just sleeps on a latch when it has nothing to do, so no wasted cycles.

Asking the postmaster seemed the easier option, I guess I could have
chosen the other way also.

I'll look at this when this is the last thing left to resolve to see
if that improves things.

>> Cleaned up the points noted, new patch attached in case you wish to
>> review further.
>>
>> Still has bug, so still with me to fix.
>
> Thanks! Will review further.

Much appreciated.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services