Avoid truncated or zero-padded copies of replaced files in backups Base backups call stat() on each file while scanning the data directory, and later send exactly that many bytes. If the file is replaced by for example a concurrent rename(), the backup contains the new file truncated or zero-padded to the size of the old one. This is harmless for relation files as WAL replay repairs them. However, it causes harm for non-relation files manipulated as temporary file renamed in place.
Here is a list of non-relation files that use a temporary file followed by a final rename() (I may be missing some): * postgresql.auto.conf * pg_logical/replorigin_checkpoint (a damaged copy fails its CRC check and prevents startup) * pg_prewarm's autoprewarm.blocks * pg_stash_advice.tsv. When sending files that are not relation files, fstat() is called again on the opened file and the refreshed stats are used for the tar header and the backup manifest. Since the rename is atomic, the opened file is always complete. Relation files keep using the earlier stat, to avoid copying data that WAL replay would restore anyway (because that's cheaper). Back-patch down to v15. v14 is going to be EOL soon, so I have decided to leave it out of the picture (risk/reward thing). Author: David Steele <[email protected]> Reviewed-by: Chao Li <[email protected]> Reviewed-by: Michael Paquier <[email protected]> Reviewed-by: Shihao Zhong <[email protected]> Discussion: https://postgr.es/m/cagrkxqs_on-plgcv6xjh8mvghdcpmfwtythw3r8pykug+hs...@mail.gmail.com Backpatch-through: 15 Branch ------ REL_19_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/2bfed4d18788586940c926e16ee0cebab9e47780 Modified Files -------------- src/backend/backup/basebackup.c | 33 ++++++++++++++++++++++++--------- 1 file changed, 24 insertions(+), 9 deletions(-)
