On Wed, 2006-11-01 at 12:05 -0500, Tom Lane wrote: > "Simon Riggs" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
