Josh Berkus wrote: > Here's a way to trap yourself: > > (1) Set up an HS/SR master > (2) pg_start_backup on the master > (3) clone the master to 1 or more slaves > (4) Fast shutdown the master (without pg_stop_backup) > (5) Restart the master > (6) Bring up the slaves > > Result: the slaves will come up fine in recovery mode. However, they > will never switch over to HS mode or start SR. You will not be able to > pg_stop_backup() on the master. At this point, you have no option but > to shut down the slaves and re-clone. > > The only reason why this is somewhat problematic for users is that you > will not get any messages from the master or the slaves to indicate why > they won't switch modes. So I can imagine someone wasting a lot of time > troubleshooting the wrong problems. > > Suggested resolution: I don't think there's and logical "fix" for this > case; it should just be added to the docs as a failure/troubleshooting > condition.
Hmm, we could throw an error in the standby, when we see a shutdown checkpoint while we're waiting for an end-backup record. If the database was shut down before pg_stop_backup(), we know that the backup was cancelled and the end-backup record we're waiting for will never arrive. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
