> Wrong. The database cannot check all data for consistency > upon backup. For one, that would take way too long. Well, what I meant, was that it would stop the database if it couldn't apply one of the transaction logs for whatever reason. It wasn't "inconsistent enough" for that. :) > If you backup the standby, then you won't have a backup_label file. > You cannot restore a backup without that. Well, the backup_label gets copied to the archive log path when pg_stop_backup gets called. So, I do have it. But beyond that, I have the start/stop WAL locations, so I can get all the required files to apply, which are all that is really necessary. > Moreover, recovery needs a checkpoint/restartpoint to start. > Restartpoints on the standby won't be the same as checkpoints > on the primary, so I believe that even with the backup_label > file you would not be able to restore the data. I suppose I could build in a function to pause the backup until the restartpoint replays on the replica. Then at least, the backup "starts" on both systems with the same assumptions. -- Shaun Thomas OptionsHouse | 141 W. Jackson Blvd | Suite 500 | Chicago IL, 60604 312-676-8870 sthomas@xxxxxxxxxxxxxxxx ______________________________________________ See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
