I've been using a base backup script that takes special care to have pg_control be the last file it grabs. And I see that basebackup.c takes similar care:
https://git.postgresql.org/gitweb/?p=postgresql.git;a=blobdiff;f=src/backend/replication/basebackup.c;h=81203c9f5ac9dbf38da09e1ff55b29846c83f514;hp=2fa1f5461356a191559b93b591c9037c6c75b389;hb=8366c7803ec3d0591cf2d1226fea1fee947d56c3;hpb=74ab96a45ef6259aa6a86a781580edea8488511a But I need to swallow my pride and admit I'm not sure how to reason about this. I think I'm being spooked by language in the "WAL Internals" documentation section: "... the checkpoint's position is saved in the file pg_control. Therefore, at the start of recovery, the server first reads pg_control and then the checkpoint record; then it performs the REDO operation by scanning forward from the log position indicated in the checkpoint record." >From that description alone, I'd imagine a danger in redoing from a base backup in which pg_control was copied last. What if another checkpoint was made (after the one done by pg_start_backup) during the course of the backup, and the late-copied pg_control refers to it, but some of the files had been copied into the base backup too early to reflect it? Looking harder, I think I see that the special care to grab pg_control last was introduced for the case of taking a base backup from a standby, and perhaps only matters in that case. The long discussion seems to be this one: https://www.postgresql.org/message-id/201108050646.p756kHC5023570%40ccmds32.silk.ntts.co.jp What I think I've gleaned is: 1. The description in the doc ("at the start of recovery, the server first reads pg_control and the checkpoint record") only applies to the kind of recovery that happens in an unexpected restart, using the files that are present; it's not the whole story for the kind of recovery that begins with a base backup. 2. In the case of recovery from a backup (that was taken from a master), both the start and end location in pg_control are disregarded, in favor of the backup label file and the backup end WAL record, respectively, so it doesn't matter a whit whether pg_control was copied early or late. 3. In recovery from a backup taken from a standby, there is a backup label file but no backup end WAL record, so the 'minimum recovery ending location' in pg_control has to be used, and that's why the fuss about copying pg_control last when backing up from a standby. Did I get that right? If so, would it be worth adding some words to that paragraph in "WAL Internals", to clarify that the pg_control checkpoint position is not relied on when starting recovery with a backup label present, and therefore it isn't scary to copy pg_control late in the backup? It all seems to make sense ultimately, but took a lot of reading and head scratching to get there. -Chap
