Re: BUG #15467: The database subdirectory "pg_tblspc/1932420460/PG_10_201707211/16400"is missing.
От | tsuraan |
---|---|
Тема | Re: BUG #15467: The database subdirectory "pg_tblspc/1932420460/PG_10_201707211/16400"is missing. |
Дата | |
Msg-id | CALKcMwLFvyAC6C6TAai9OQf3npNu1HAw9SPjs=6YYZHyT54FHA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #15467: The database subdirectory "pg_tblspc/1932420460/PG_10_201707211/16400" is missing. (Andrew Gierth <andrew@tao11.riddles.org.uk>) |
Ответы |
Re: BUG #15467: The database subdirectory "pg_tblspc/1932420460/PG_10_201707211/16400" is missing.
|
Список | pgsql-bugs |
> Does that error persist if you delete all files named pg_internal.init > in the data dir? (those files are a cache of the system tables and are > regenerated on the next new connection if they are missing) There were a few of those files, so I removed them: $ find data -name pg_internal.init data/base/1/pg_internal.init data/base/16401/pg_internal.init data/base/12292/pg_internal.init data/base/12291/pg_internal.init data/base/16402/pg_internal.init data/global/pg_internal.init $ find data -name pg_internal.init -exec rm {} \; $ find data -name pg_internal.init $ Starting up postgres again and querying pg_database still gives the same cache lookup error. Another person noticed that the missing directory (pg_tblspc/1932420460/PG_10_201707211/16400) corresponded to an existing directory under data/base/16400, so he copied the contents from data/base/16400 into pg_tblspc/1932420460/PG_10_201707211/16400 (making the previously non-existent parent path "pg_tblspc/1932420460/PG_10_201707211/" along the way). Doing that allowed the main database to once again be queried, and all the data appears to be present. That system still can't query its pg_databases table, so I assume it's still pretty badly broken, but at least we can try a pg_dump and recovery onto a new, clean, system. I still have my copy of the broken database though, and I'd love to know if there's a proper fix for it, so I'll keep this discussion going as long as anybody has ideas :)
В списке pgsql-bugs по дате отправления: