Simon Riggs wrote:
>>>>>>> So if we perform our database backups with incremental
>>>>>>> backups as described above, we could end up with additional
>>>>>>> files after the restore, because PostgreSQL files can get
>>>>>>> deleted (e.g. during DROP TABLE or TRUNCATE TABLE).
>>>>>>>
>>>>>>> Could such "resurrected" files (data files, files in
>>>>>>> pg_xlog, pg_clog or elsewhere) cause a problem for
>>>>>>> the database?
>>>
>>> The backup is not instantaneous, so there is no single time
>>> at which the hot backup takes place. So deciding whether
>>> a file has changed based upon a comparison of two file timestamps
>>> cannot work. You would need to take timestamps for the file both
>>> before the pg_start_backup() and after the pg_stop_backup()
>>> of the file for both full and incremental backups.
>>> If all four timestamps are equivalent, then you are safe.
I think that understanding is finally dawning here.
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?
Sorry for being such a blockhead, I can see now why this
is a bad idea.
Thanks for the patience,
Laurenz Albe
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
