| From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
|---|---|
| To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: WAL Restore process during recovery |
| Date: | 2012-01-24 09:43:47 |
| Message-ID: | CAHGQGwEK4CJ6TJKrE-ZUFzGA7s2CWmpbYxsqyvDXyO_04jvDBA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2012-01-24 09:49:16 | Re: WAL Restore process during recovery |
| Previous Message | Thomas Ogrisegg | 2012-01-24 09:39:19 | PATCH: pg_basebackup (missing exit on error) |