Re: DeArchiver process

On Wed, Nov 2, 2011 at 4:14 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> 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.

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