From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: DeArchiver process |
Date: | 2011-11-02 16:14:04 |
Message-ID: | CA+TgmoY7VF+rBwTYxb4qd6p9Jcs7GghWx=cZQTZEUW1HXQamMQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Nov 2, 2011 at 11:56 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> My solution is to create a new process called the DeArchiver. This
> will run restore_command in a tight loop until the number of files
> would exceed wal_keep_files, then sleep. Each time the DeArchiver
> executes restore_command it will set the return code and if rc=0 the
> new XLogRecPtr reached. If standby_mode = on it will continue to retry
> indefinitely.
Are you thinking of reusing the existing GUC wal_keep_segments (not
wal_keep_files), or creating a new one? I'd suggest creating a new
one, so as to avoid having a GUC that does one thing on the master and
something quite different on the slave.
> Which do we prefer "DeArchiver", "Restore process", or "WALFileReceiver".
My personal preference would be restore process, since we already use
the name restore_command.
> Thoughts?
+1. Great idea.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-11-02 16:15:57 | Re: pgsql: Reduce checkpoints and WAL traffic on low activity database serv |
Previous Message | Robert Haas | 2011-11-02 16:01:35 | Re: [v9.2] Fix Leaky View Problem |