Странное поведение Postgresql Ubuntu (несовместимость версий?)

Я пытаюсь запустить базу данных postgresql в Ubuntu 16.04 LTS.

Сначала я установил postgres, используя sudo apt-get install postgresql, который установил версию 9.5.1. Затем я создал другого пользователя и новую базу данных. Я предоставил все привилегии для новой базы данных новому новому пользователю и также установил владельца для нового пользователя.

Я подключился к новой базе данных и заполнил ее, восстановив обычную резервную копию (дамп), которую я создал из другой базы данных (с postgresql версии 9.2) с помощью \i /path/to/dump.sql. У меня не было ошибок, и когда я набрал \dt, я получил список с таблицами.

Проблема в следующем: когда я сейчас отключаюсь (\q) и снова подключаюсь (так же, как я подключался раньше, sudo psql -U "username" dbname) и снова набираю \dt, он говорит: «Никаких отношений не найдено». Когда я пытаюсь заполнить его снова, я получаю кучу ошибок, таких как «Имя отношения отношения уже существует».

Другая проблема/симптом появляется, когда я пытаюсь использовать pgAdmin (установленный через sudo apt-get install pgadmin3). При попытке подключиться с помощью локального хоста я не могу подключиться с помощью вновь созданного пользователя (которого я могу подключить с терминала). Но я могу подключиться с помощью postgres с паролем, который я установил через Терминал. Я не вижу ни одной БД, созданной вручную из командной строки из pgAdmin, хотя.

Так что да, я предполагаю, что по крайней мере одна проблема может заключаться в несовместимости версий между 9.2 и 9.5. Есть ли способ проверить/исправить это? Но я также думаю, что должны быть и другие проблемы.


ubuntu postgresql ubuntu-16.04 pgadmin postgresql-9.5
person Jdv    schedule 06.05.2016    source источник
comment
мое предположение, а вы пробовали делать дамп на 9.2 с сервера 9.5? Когда я перехожу на более новую версию, я обычно всегда удаляю ее удаленно на более новый сервер.   -  person LongBeard_Boldy    schedule 06.05.2016
comment
Наоборот. У меня есть работающий 9,2 дБ, который я сделал резервную копию с помощью простого дампа. Пытаюсь восстановить этот дамп до 9.5.   -  person Jdv    schedule 06.05.2016
comment
плохой английский, я имею в виду вызов скрипта дампа (в котором вы устанавливаете исходную базу данных и сервер версии 9.2) на машине 9.5 с помощью 9.5 версии PG_DUMP, а затем восстанавливаете его.   -  person LongBeard_Boldy    schedule 06.05.2016
comment
@ e4c5 Должен ли я фиксировать при работе с терминала Ubuntu и при подключении к базе данных? Я только что попытался набрать commit; после нескольких изменений и он говорит Предупреждение: транзакция не выполняется   -  person Jdv    schedule 06.05.2016
comment
Нет, я имел в виду фиксацию после импорта. Должен признаться, что я никогда не использовал \i для загрузки дампа базы данных, но, поскольку дамп находится в транзакции, я думал, что он не фиксируется. Конечно, ошибка, с которой вы столкнулись, типична для незафиксированной транзакции.   -  person e4c5    schedule 06.05.2016
comment
Я попробовал то же самое с psql -U username -f backup.sql dbname с тем же результатом: / Все выглядело нормально, я получил кучу сообщений CREATE TABLE и ALTER TABLE. Но когда я подключился к базе данных, он снова показывает, что отношения не найдены.   -  person Jdv    schedule 06.05.2016
comment
Какие схемы есть в базе? Выполните \dn в приглашении psql и, как только найдете \d my_schema.*   -  person Clodoaldo Neto    schedule 06.05.2016
comment
а как насчет использования pg_restore postgresql.org/docs/9.2/static/ приложение-pgrestore.html   -  person e4c5    schedule 06.05.2016

Ответы (1)


arrow_upward
1
arrow_downward

То, что вы описываете, может произойти, если дамп SQL содержит команду SET search_path TO..., которая устанавливает для него значение, отличное от значения, которое ваш пользователь имеет по умолчанию.

Таким образом, он не только создаст свои таблицы и другие объекты в этой схеме, но и оставит этот search_path для остальной части сеанса, поэтому, когда вы выполните \dt в том же сеансе, он увидит и перечислит вновь созданные таблицы.

Но когда вы выходите и снова входите в psql, этот search_path больше не действует, вы возвращаетесь к стандартному search_path вашего пользователя, который предположительно не достигает схемы, поэтому \dt больше не "видит" никакую таблицу.

Вы можете использовать show search_path, чтобы проверить этот параметр в сеансе psql, и grep "SET search_path" в файле SQL, чтобы проверить, на что он установлен.

Судя по комментарию, это так: дамп создает таблицы в схеме, которая находится за пределами пути поиска пользователя по умолчанию.

Возможным решением для бесперебойной работы этого пользователя было бы обновление его пути поиска, чтобы он всегда сначала достигал этой схемы. Это можно сделать с помощью:

ALTER USER username SET search_path TO schema1,"$user",public;

где schema1 — это то, на что ссылается дамп SQL и где он создал таблицы.

person Daniel Vérité    schedule 06.05.2016
comment
Эй, спасибо за ответ. На самом деле я нашел команду search_path в дампе. Так же я проверил показать search_path сразу после заливки БД из дампа. В этот момент было установлено значение в дампе (somestring, pg_catalog). Затем я отключился и снова подключился, и теперь он отображается как $user, public. Можете ли вы сказать мне, как исправить эту проблему? - person Jdv; 06.05.2016
comment
Привет, поэтому я установил search_path к базе данных на то, что установлено в дампе, и теперь pgadmin показывает таблицу :) спасибо! - person Jdv; 06.05.2016
comment
@JacobS: я просто предлагал сделать это на уровне пользователя в моем редактировании, но это работает и на уровне базы данных. - person Daniel Vérité; 06.05.2016