On Wed, 2006-11-01 at 12:05 -0500, Tom Lane wrote:
> "Simon Riggs" <simon@2ndquadrant.com> writes:
> > Enclose a patch for new WAL records for relcache invalidation.
>
> I don't think this works. RelationCacheInitFileInvalidate is executed
> post-commit, which means that there's a window between commit and where
> you propose to write the WAL entry. A crash and restart in that
> interval would leave the catalog changes committed, but not reflected
> into pg_internal.init.
Surely you are pointing out a bug, no?
If a backend did crash, the init file would be wrong and we'd get
exactly the same wrong relfilenode errors we got after that PITR.
The issue must surely be that the patch isn't wrong per se, just that
RelationCacheInitFileInvalidate is called too late and that requires an
additional fix. Are we certain that a crash between commit and
invalidation will cause a PANIC that takes down the server? Doesn't look
like its in a critical section to me.
> I think we're probably better off to just forcibly remove the init file
> during post-recovery cleanup. The easiest place to do this might be
> BuildFlatFiles, which has to scan pg_database anyway ...
I can do this - I don't have a problem there, but the above issue just
occurred to me so I wonder now if its the right thing to do.
PITR will be always-safe but normal operation might not be.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com