summaryrefslogtreecommitdiff
path: root/src/backend/backup
diff options
context:
space:
mode:
authorRobert Haas <rhaas@postgresql.org>2023-02-02 12:04:16 -0500
committerRobert Haas <rhaas@postgresql.org>2023-03-06 10:15:32 -0500
commit33352b9279f5e109aae74d61531d33d8fb12253e (patch)
treed8b9a65d89cafd56226282bd682de030ac4f5a3a /src/backend/backup
parentd3406d80360776bbcafa05d8b966806012f9594e (diff)
downloadpostgresql-33352b9279f5e109aae74d61531d33d8fb12253e.tar.gz
In basebackup.c, perform end-of-file test after checksum validation.
We read blocks of data from files that we're backing up in chunks, some multiple of BLCKSZ for each read. If checksum verification fails, we then try rereading just the one block for which validation failed. If that block happened to be the first block of the chunk, and if the file was concurrently truncated to remove that block, then we'd reach a call to bbsink_archive_contents() with a buffer length of 0. That causes an assertion failure. As far as I can see, there are no particularly bad consequences if this happens in a non-assert build, and it's pretty unlikely to happen in the first place because it requires a series of somewhat unlikely things to happen in very quick succession. However, assertion failures are bad, so rearrange the code to avoid that possibility. Patch by me, reviewed by Michael Paquier. Discussion: http://postgr.es/m/CA+TgmoZ_fFAoU6mrHt9QBs+dcYhN6yXenGTTMRebZNhtwPwHyg@mail.gmail.com
Diffstat (limited to 'src/backend/backup')
-rw-r--r--src/backend/backup/basebackup.c17
1 files changed, 9 insertions, 8 deletions
diff --git a/src/backend/backup/basebackup.c b/src/backend/backup/basebackup.c
index 3fb9451643..1be55e485f 100644
--- a/src/backend/backup/basebackup.c
+++ b/src/backend/backup/basebackup.c
@@ -1568,14 +1568,6 @@ sendFile(bbsink *sink, const char *readfilename, const char *tarfilename,
len, readfilename, true);
/*
- * If we hit end-of-file, a concurrent truncation must have occurred.
- * That's not an error condition, because WAL replay will fix things
- * up.
- */
- if (cnt == 0)
- break;
-
- /*
* The checksums are verified at block level, so we iterate over the
* buffer in chunks of BLCKSZ, after making sure that
* TAR_SEND_SIZE/buf is divisible by BLCKSZ and we read a multiple of
@@ -1677,6 +1669,15 @@ sendFile(bbsink *sink, const char *readfilename, const char *tarfilename,
}
}
+ /*
+ * If we hit end-of-file, a concurrent truncation must have occurred.
+ * That's not an error condition, because WAL replay will fix things
+ * up.
+ */
+ if (cnt == 0)
+ break;
+
+ /* Archive the data we just read. */
bbsink_archive_contents(sink, cnt);
/* Also feed it to the checksum machinery. */