Обсуждение: BUG #8247: Duplicate database names - pg_dump backup fails
The following bug has been logged on the website: Bug reference: 8247 Logged by: Paul Macdonald Email address: paul.macdonald@ssc-spc.gc.ca PostgreSQL version: Unsupported/Unknown Operating system: Debian Sarge Description: Postgres version: 7.4.7-6sarge1 Issue: pg_dump fails due to unexpected duplication of database name ("avipads"). Dropdb will remove one instance of the database name, but unable to remove the second instance. Scope: This specific database is used on multiple servers nationally. Three of our servers have this issue, the majority do not. The issue only affects our ability to locally backup the "avipads" database. The servers having the problem are clustered pair systems. The other cluster pair servers do not have the problem. Name | Owner | Encoding -----------+-------------+----------- avipads | | SQL_ASCII avipads | avimgr | SQL_ASCII rtadb | rtafbackend | SQL_ASCII rtafdb | rtafbackend | SQL_ASCII template0 | postgres | SQL_ASCII template1 | postgres | SQL_ASCII When a new version of the database is available for installation, the installation script does the following steps a) remove the old database su - avimgr -c "dropdb --quiet --username=avimgr avipads" || true b) remove the avimgr user su - postgres -c "dropuser --quiet avimgr" || true c) create the avimgr Posgresql user su - postgres -c "createuser avimgr --no-adduser --createdb --quiet; true" 2> /dev/null d) install the new database su - avimgr -c "/apps/avipads/voicedb/restorevoice /apps/avipads/voicedb/vdb2.5.1.pg" I would like details on how to successfully remove both "avipads" databases, in order to have the pg_dump be functional again.
paul.macdonald@ssc-spc.gc.ca writes: > Postgres version: 7.4.7-6sarge1 Egad. Not only has 7.4 been EOL for years, but the last release in that series was 7.4.30. You are missing many years' worth of bug fixes. You really, really, really need to get off of that PG version ASAP. > Issue: pg_dump fails due to unexpected duplication of database name > ("avipads"). Dropdb will remove one instance of the database name, but > unable to remove the second instance. I suspect this is evidence of transaction ID wraparound in the pg_database catalog. See if "VACUUM FULL pg_database" makes things any saner. (Delete the one database that you're able to get rid of first.) regards, tom lane