On Mon, Mar 14, 2016 at 6:54 PM, Shulgin, Oleksandr <oleksandr.shulgin@xxxxxxxxxx> wrote: > On Mon, Mar 14, 2016 at 6:28 PM, John Lumby <johnlumby@xxxxxxxxxxx> wrote: >> 1. shut down both new Master and intended-to-be-new-Standby >> 2. on intended-to-be-new-Standby, remove the entire content of pg_xlog and >> the global/pg_control >> 3. from new Master , tar + scp the entire content of pg_xlog and the >> global/pg_control to intended-to-be-new-Standby This is not robust and will corrupt your standby. Just take the case of a relation data block modified on the to-be-new standby, and not replayed since the last checkpoint before WAL forked: data will be corrupted. Inconsistent pg_clog will likely break things. > That does seem like a very risky strategy to me. Have you taken a look at > pg_rewind (which is now part of the distribution)? pg_rewind has been designed for that, and ensures that the soon-to-be-standby has a minimum recovery target sufficient. You had better use it. -- Michael -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
