Simon Riggs <si...@2ndquadrant.com> writes: > If you were running pg_standby as the restore_command then this error > wouldn't happen. So you need to explain why running pg_standby cannot > solve your problem and why we must fix it by replicating code that has > previously existed elsewhere.
Let me try. pg_standby will not let the server get back to streaming replication mode once it's done with driving the replay of all the WAL files available in the archive, but will have the server sits there waiting for the next file. The way we want that is implemented now is to have the server switch back and forth between replaying from the archive and streaming from the master. So we want the server to restore from the archive the same way pg_standby used to, except that if the archive does not contain the next WAL files, we want to get back to streaming. And the archive reading will resume at next network glitch. I think it's the reasonning, I hope it explains what you see happening. -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
