On Tue, Jan 24, 2012 at 6:49 PM, Simon Riggs <si...@2ndquadrant.com> wrote: > On Tue, Jan 24, 2012 at 9:43 AM, Fujii Masao <masao.fu...@gmail.com> wrote: >> On Tue, Jan 24, 2012 at 12:23 AM, Simon Riggs <si...@2ndquadrant.com> wrote: >>> On Mon, Jan 23, 2012 at 12:23 PM, Fujii Masao <masao.fu...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
