Tom, Simon et al; Please clarify. PostgreSQL 8.1.5 on sparc-sun-solaris2.9, compiled by GCC gcc (GCC) 3.4.2
We're getting ready to init a new warm standby instance based on last night's snapshot of running prod server. I see a few of these pg_internal.init files in the cluster as it's being unpacked. Same warm standby instance may sit for weeks gobbling up WALs from the prod server then be finally brought live. Question; Is it safe to delete the .init files now (before starting recovery), or perhaps unconditionally right after going live? In other words, is there any sure fire preventative measure that I can apply to guarantee against the fault that started this threadd? Tom wrote: > Meanwhile, if you're trying to recover from a PITR backup and it's not > working, try removing any pg_internal.init files you can find. Comment above seems to suggest not touching existing pg_internal.init files unless a problem is seen. Thanks "Simon Riggs" <[EMAIL PROTECTED]> writes: > 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 > -- ------------------------------------------------------------------------------- Jerry Sievers 305 854-3001 (home) WWW ECommerce Consultant 305 321-1144 (mobile http://www.JerrySievers.com/ ---------------------------(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
