[MASSMAIL]pg_combinebackup fails on file named INCREMENTAL.*

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