On Tue, Dec 12, 2017 at 8:48 PM, Stephen Frost <sfr...@snowman.net> wrote: > If the persistence is changed then the table will be written into the > WAL, no? All of the WAL generated during a backup (which is what we're > talking about here) has to be replayed after the restore is done and is > before the database is considered consistent, so none of this matters, > as far as I can see, because the drop table or alter table logged or > anything else will be in the WAL that ends up getting replayed.
I can't see a hole in this argument. If we copy the init fork and skip copying the main fork, then either we skipped copying the right file, or the file we skipped copying will be recreated with the correct contents during WAL replay anyway. We could have a problem if wal_level=minimal, because then the new file might not have been WAL-logged; but taking an online backup with wal_level=minimal isn't supported precisely because we won't have WAL replay to fix things up. We would also have a problem if the missing file caused something in recovery to croak on the grounds that the file was expected to be there, but I don't think anything works that way; I think we just assume missing files are an expected failure mode and silently do nothing if asked to remove them. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
