On Sun, Aug 6, 2017 at 3:22 AM, Robert Haas <robertmh...@gmail.com> wrote: > All of (1)-(3) are legitimate user choices, although not everyone will > make them. (4) is unfortunately the procedure recommended by our > documentation, which is where the problem comes in. I think it's > pretty lame that the documentation recommends ignoring the return > value of pg_stop_backup(); ISTM that it would be very wise to > recommend cross-checking the return value against the WAL files you're > keeping for the backup. Even if we thought the waiting logic was > working perfectly in every case, having a cross-check on something as > important as backup integrity seems like an awfully good idea.
I would got a little bit more far and say that this is mandatory as the minimum recovery point that needs to be reached is the LSN returned by pg_stop_backup(). For backups taken from primaries, this is a larger deal because XLOG_BACKUP_END may not be present if the last WAL segment switched is not in the archive. For backups taken from standbys, the thing is more tricky as the control file should be backed up last. I would think that the best thing we could do is to extend pg_stop_backup a bit more so as it returns the control file to write in the backup using a bytea to hold the data for example. > I think the root of this problem is that commit > 7117685461af50f50c03f43e6a622284c8d54694 did only a pretty perfunctory > update of the documentation, as the commit message itself admits: > > Only reference documentation is included. The main section on > backup still needs > to be rewritten to cover this, but since that is already scheduled > for a separate > large rewrite, it's not included in this patch. > > But it doesn't look like that ever really got done. > https://www.postgresql.org/docs/10/static/continuous-archiving.html#backup-lowlevel-base-backup > really doesn't talk at all about standbys or differences in required > procedures between masters and standbys. It makes statements that are > flagrantly riduculous in the case of a standby, like claiming that > pg_start_backup() always performs a checkpoint and that pg_stop_backup > "terminates the backup mode and performs an automatic switch to the > next WAL segment." Well, obviously not. Yep. > And at least to me, that's the real bug here. Somebody needs to go > through and fix this documentation properly. So, Magnus? :) -- Michael -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers