On Wed, Oct 29, 2014 at 12:43 PM, Maeldron T. <maeld...@gmail.com> wrote: > Thank you, Robert. > > I thought that removing the recovery.conf file makes the slave master only > after the slave was restarted. (Unlike creating the a trigger_file). Isn't > this true?
Yes, but after the restart, the slave will also rewind to the most recent restart-point to begin replay, and some of the sanity checks that recovery.conf enforces will be lost during that replay. A safe way to do this might be to shut down the master, make a note of the ending WAL position on the master, and then promote the slave (without shutting it down) once it's reached that point in replay. > I also thought that if there was a crash on the original master and it > applied WAL entries on itself that are not presented on the slave then it > will throw an error when I try to connect it to the new master (to the old > slave). I don't think you're going to be that lucky. > It would be nice to know as creating a base_backup takes much time. rsync can speed things up by copying only changed data, but yes, it's a problem. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
