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. 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
