Re: [GENERAL] "Resurrected" data files - problem?

From: Albe Laurenz <laurenz.albe(at)wien.gv.at>
Date: Fri Nov 09 2007 - 11:18:20 EST

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 Received on Fri Nov 9 11:22:22 2007