Hackers,
Since incremental backup is using INCREMENTAL as a keyword (rather than
storing incremental info in the manifest) it is vulnerable to any file
in PGDATA with the pattern INCREMENTAL.*.
For example:
$ pg_basebackup -c fast -D test/backup/full -F plain
$ touch test/data/INCREMENTAL.CONFIG
$ /home/dev/test/pg/bin/pg_basebackup -c fast -D test/backup/incr1 -F
plain -i /home/dev/test/backup/full/backup_manifest
$ /home/dev/test/pg/bin/pg_combinebackup test/backup/full
test/backup/incr1 -o test/backup/combine
pg_combinebackup: error: could not read file
"test/backup/incr1/INCREMENTAL.CONFIG": read only 0 of 4 bytes
pg_combinebackup: removing output directory "test/backup/combine"
This works anywhere in PGDATA as far as I can see, e.g.
$ touch test/data/base/1/INCREMENTAL.1
Or just by dropping a new file into the incremental backup:
$ touch test/backup/incr1/INCREMENTAL.x
$ /home/dev/test/pg/bin/pg_combinebackup test/backup/full
test/backup/incr1 -o test/backup/combine
pg_combinebackup: error: could not read file
"test/backup/incr1/INCREMENTAL.x": read only 0 of 4 bytes
pg_combinebackup: removing output directory "test/backup/combine"
We could fix the issue by forbidding this file pattern in PGDATA, i.e.
error when it is detected during pg_basebackup, but in my view it would
be better (at least eventually) to add incremental info to the manifest.
That would also allow us to skip storing zero-length files and
incremental stubs (with no changes) as files.
Regards,
-David