On Tue, Jan 24, 2012 at 6:49 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Tue, Jan 24, 2012 at 9:43 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
>> On Tue, Jan 24, 2012 at 12:23 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>> On Mon, Jan 23, 2012 at 12:23 PM, Fujii Masao <masao.fujii@gmail.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.
Right, since walrestore process wakes up just every 10 seconds, a waste of
cycle is low. But what I feel uncomfortable is that walrestore process has
nothing to do *from start to end*, when restore_command is not specified,
but it's started up. I guess that many people would get surprised at that.
Of course, if restore_command can be changed without restarting the server,
I agree with you because walrestore process might do an useful activity
later. But currently not.
> 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.
Okay.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
