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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
