Re: DeArchiver process - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: DeArchiver process
Date
Msg-id CA+U5nMJextZEgA9hYzBzP+9vBYtJ_P=093Rv9C4BMpL2oLnj4A@mail.gmail.com
Whole thread Raw
In response to Re: DeArchiver process  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: DeArchiver process
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: heap_page_prune comments
Next
From: Robert Haas
Date:
Subject: Re: DeArchiver process