Tom Lane wrote:
>>> The problem you see is that the backup software might decide
>>> that the file has not been changed, skip it and go on backing
>>> up other files, but the file can still be modified before
>>> pg_stop_backup(), correct?
>
>> Correct.
>
> Surely that's nonsense --- otherwise a time-extended base backup
> could not work either.
>
> What is required of the filesystem backup process is that each 8K page
> of each file be restored to a state that it had at some time between
> pg_start_backup and pg_stop_backup. The exact time can be
> different for different pages. I don't see a reason to think that a
> base+incremental backup method can't meet that requirement.
Ho hum, you're right.
In the scenario on top, the file that was not backed up during
incremental backup will - after restore of full and incremental
backup - be in a state that was valid at some time between
pg_start_backup and pg_stop_backup.
So that should work.
What remains are the resurrected files. You said that they shouldn't
be a problem, right? What happens if PostgreSQL wants to create a
new data file and that file already exists? Could it lead to
problems in other directories like pg_clog?
Thank you all for your replies, BTW.
Yours,
Laurenz Albe
