On Wed, Nov 2, 2011 at 4:14 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Nov 2, 2011 at 11:56 AM, Simon Riggs <si...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers