On Tue, 17 Oct 2006, Tom Lane wrote:
> Dirk Lutzebaeck and I just spent a tense couple of hours trying to
> figure out why a large database Down Under wasn't coming up after being
> reloaded from a base backup plus PITR recovery. The symptoms were that
> the recovery went fine, but backend processes would fail at startup or
> soon after with "could not open relation XX/XX/XX: No such file" type of
> errors.
>
> The answer that ultimately emerged was that they'd been running a
> nightly maintenance script that did REINDEX SYSTEM (among other things
> I suppose). The PITR base backup included pg_internal.init files that
> were appropriate when it was taken, and the PITR recovery process did
> nothing whatsoever to update 'em :-(. So incoming backends picked up
> init files with obsolete relfilenode values.
Ouch.
> We don't actually need to *update* the file, per se, we only need to
> remove it if no longer valid --- the next incoming backend will rebuild
> it. I could see fixing this by making WAL recovery run around and zap
> all the .init files (only problem is to find 'em), or we could add a new
> kind of WAL record saying "remove the .init file for database XYZ"
> to be emitted whenever someone removes the active one. Thoughts?
The latter seems the Right Way except, I guess, that the decision to
remove the file is buried deep inside inval.c.
Thanks,
Gavin
