On Wed, Nov 2, 2011 at 4:14 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Wed, Nov 2, 2011 at 11:56 AM, Simon Riggs <simon@2ndquadrant.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.
Any standby can now become a sender node, so the meaning in that case
would be the same. That takes a little time to get your head around,
and I'm not used to it myself yet.
I guess you might say that you know for certain that a node will never
be a relay node, and so a different meaning is possible, but it seems
easier to avoid adding a new parameter just for that case.
>> Which do we prefer "DeArchiver", "Restore process", or "WALFileReceiver".
>
> My personal preference would be restore process, since we already use
> the name restore_command.
Restore process, with file called restore.c in src/backend/postmaster
(or src/backend/replication?)
We can change that again later, but its enough to be getting on with.
>> Thoughts?
>
> +1. Great idea.
Thanks.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services