On Wed, Sep 27, 2006 at 04:52:51PM -0400, Tom Lane wrote: > "Jim C. Nasby" <[EMAIL PROTECTED]> writes: > > Then again, if we're doing that, we could probably just nuke 'em... > > This has been considered and rejected before, on the grounds that > removing files you don't know the source of is a good way to lose data. > > Come to think of it, that argument bears on the immediate problem too. > The way createdb() is coded, if it gets a failure (like "File exists") > trying to create the database's directories, it will attempt to apply > remove_dbtablespaces() to clean up after itself. This would result in > removing the pre-existing directory, which violates the principle of > not removing unexpected files. So now I'm starting to think we do need > a check-for-conflicting-files step in createdb.
I think it would be really useful to tell the DBA that there's a bunch of files in $PGDATA that are probably dead. If stuff had suddenly disappeared out of the catalog I'd certainly like to know it. -- Jim Nasby [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---------------------------(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
