Re: WAL Restore process during recovery
От | Fujii Masao |
---|---|
Тема | Re: WAL Restore process during recovery |
Дата | |
Msg-id | CAHGQGwEK4CJ6TJKrE-ZUFzGA7s2CWmpbYxsqyvDXyO_04jvDBA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: WAL Restore process during recovery (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: WAL Restore process during recovery
Re: WAL Restore process during recovery |
Список | pgsql-hackers |
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. > 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. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: