Сбой инструмента pg_upgrade: недопустимые «неизвестные» пользовательские столбцы

Question

Обновление Postgresql с 9.6 до 10.4 (на Fedora 28) застряло у меня: в одной таблице в одной базе данных есть столбец с типом данных «unknown».Я бы с радостью удалил этот столбец, но поскольку я не могу запустить службу postgresql (поскольку «была найдена старая версия формата базы данных»), у меня нет доступа к базе данных.Более подробно:

postgresql-setup --upgrade терпит неудачу.

/var/lib/pgsql/upgrade_postgresql.log приписывает этот сбой столбцу с типом данных «unknown»: «... Проверка на недопустимые« неизвестные »пользовательские столбцы: fatal.... проверьте tables_using_unknown.txt ".И "tables_using_unknown.txt" указывает один столбец в одной таблице, который я хотел бы удалить, но не могу, потому что не могу запустить сервер:

systemctl start postgresql.service происходит сбой, и состояние systemctl postgresql.service жалуется на «старую версию базы данных»

Я не нашел очевидного способа установить postgresql 9.6 на Fedora 28.

Есть ли способ удалить столбец без работающего сервера?Или хотя бы произвести дамп базы данных?Или я могу заставить инструмент обновления удалять столбцы с типом данных «неизвестно»?Или есть какое-то другое очевидное решение, которое мне не хватает?

Answer 1

Вот что в итоге сработало для меня:

• Я использовал докер-контейнер (на той же машине) с postgres 9.6 для доступа к «старому» каталогу базы данных,
• преобразовалпроблемный столбец от «неизвестно» до «текст» в контейнере,
• выгружал соответствующую базу данных в файл на хосте контейнера, а затем
• загружал выгруженную базу данных в среду postgres 10.4.

Не красиво, но сработало.Более подробно:

Я скопировал каталог данных postgresql (/var/lib/pgsql/data/ в Fedora) - содержащий базу данных, которую не удалось преобразовать - в новый пустой каталог /home/hj/pg-problem/.

Я создал Dockerfile (текстовый файл) с именем «Docker-pg-problem», читающий

FROM postgres:9.6
# my databases need German locale; 
# if you just need en_US, comment the next two lines out.
RUN localedef -i de_DE -c -f UTF-8 -A /usr/share/locale/locale.alias de_DE.UTF-8
ENV LANG de_DE.utf8

, и сохранил его как единственный файл в новой пустой папке /home/hj/pg-problem/docker/.

Iзапустил демон docker и запустил контейнер , который использует данные из моей копии проблемных данных (в /home/hj/pg-problem/data/) в качестве каталога данных для сервера postgres 9.6 в контейнере.(Примечание: команда "docker build" в третьей строке требует работающего подключения к Интернету, занимает некоторое время и должна сказать "Успешно собран").

root@host: cd /home/hj/pg-problem/docker
root@host: service docker start
root@host: docker build -t hj/failed-update -f Dockerfile .
root@host: docker run -it --rm -p 5431:5432 -v /home/hj/pg-problem/data:/var/lib/postgresql/data:z --name failed-update -e POSTGRES_PASSWORD=secret hj/failed-update

Затем я открыл терминал в контейнеречтобы исправить базу данных:

hj@host: docker exec -it failed-update bash

Внутри контейнера я исправил и выгрузил базу данных:

root@container: su postgres
postgres@container: psql <DB-name>
postgres@container: alter table <Table-name> alter column <Col-Name> type text;
postgres@container: \q
postgres@container: dump_db <DB-name> /var/lib/postgresql/data/dbREPAIRED.sql

Я вывел базу данных прямо в каталог данных, чтобы я мог легко получить доступ к дампуфайл с хоста докера.

На хосте докера дамп базы данных был, очевидно, в /home/hj/pg-problem/data/dbREPAIRED.sql, и оттуда я мог загрузить его в postgresql 10:

postgres@host: createdb <DB-name>
postgres@host: psql <DB-name> < /home/hj/pg-problem/data/dbREPAIRED.sql

Так какЯ был на ноутбуке с ограниченным дисковым пространством, я удалил докер:

root@host: docker rm $(docker ps -a -q)
root@host: docker rmi $(docker images -q)