Як вирішити проблеми з привілеями при відновленні бази даних PostgreSQL

Я скинув чисту, без резервної копії власника для Postgres Database з командою

pg_dump sample_database -O -c -U

Пізніше, коли я відновляю базу даних з

psql -d sample_database -U app_name

Однак я зіткнувся з декількома помилками, які не дозволяють мені відновити дані:

ERROR:  must be owner of extension plpgsql
ERROR:  must be owner of schema public
ERROR:  schema "public" already exists
ERROR:  must be owner of schema public
CREATE EXTENSION
ERROR:  must be owner of extension plpgsql

Я перекопався до простого тексту pg_dumpгенерує SQL і виявив, що він містить SQL

CREATE SCHEMA public;
COMMENT ON SCHEMA public IS 'standard public schema';
CREATE EXTENSION IF NOT EXISTS plpgsql WITH SCHEMA pg_catalog;
COMMENT ON EXTENSION plpgsql IS 'PL/pgSQL procedural language';

Я думаю, що причини полягають у тому, що користувач app_nameне має привілеїв змінювати publicсхему та plpgsql.

Як я міг вирішити це питання?

Щоб вирішити проблему, потрібно призначити належні дозволи власності. Спробуйте нижче, що має вирішити всі проблеми, що стосуються дозволу для конкретних користувачів, але як зазначено в коментарях, це не повинно використовуватися у виробництві:

root@server:/var/log/postgresql# sudo -u postgres psql
psql (8.4.4)
Type "help" for help.

postgres=# \du
               List of roles
    Role name    | Attributes  | Member of
-----------------+-------------+-----------
 <user-name>    | Superuser   | {}
                 : Create DB
 postgres       | Superuser   | {}
                 : Create role
                 : Create DB

postgres=# alter role <user-name> superuser;
ALTER ROLE
postgres=#

Тому підключіться до бази даних під обліковим записом Superuser sudo -u postgres psqlта виконайтеALTER ROLE <user-name> Superuser; операцію.

Майте на увазі, що це не найкраще рішення на сервері хостингу на декількох сайтах, тому погляньте на призначення замість них окремих ролей: https://www.postgresql.org/docs/current/static/sql-set-role.html та https : //www.postgresql.org/docs/current/static/sql-alterrole.html .

Користувачі AWS RDS, якщо ви отримуєте це, це тому, що ви не суперпользователь, і згідно з документами aws, ви не можете бути ним. Я виявив, що повинен ігнорувати ці помилки.

Для людей, які використовують хмарну платформу Google, будь-яка помилка зупинить процес імпорту. Особисто я зіткнувся з двома різними помилками, залежно від команди, яку я видав:

1- The input is a PostgreSQL custom-format dump. Use the pg_restore command-line client to restore this dump to a database.

Виникає, коли ви намагалися скинути БД у непростий текстовий формат. Тобто, коли в команді відсутній параметр -Fp або --format = plain. Однак якщо ви додасте його до своєї команди, то може виникнути така помилка:

2- SET SET SET SET SET SET CREATE EXTENSION ERROR: must be owner of extension plpgsql

Це вирішення питання я не зміг виправити , використовуючи команду , представлену в GCP документи , поради з цього поточного потоку, або після консультації з командою Google Postgres тут . Який рекомендував видавати таку команду:

pg_dump -Fp --no-acl --no-owner -U myusername myDBName > mydump.sql

Єдине, що зробило трюк у моєму випадку - це вручну редагувати файл дампа та коментувати всі команди, що стосуються plpgsql.

Я сподіваюся, що це допомагає душам, які залежать від GCP

Оновлення:

Простіше скинути файл, коментуючи розширення, тим більше, що деякі папки можуть бути величезними: pg_dump ... | grep -v -E '(CREATE\ EXTENSION|COMMENT\ ON)' > mydump.sql

Що можна звузити до plpgsql: pg_dump ... | grep -v -E '(CREATE\ EXTENSION\ IF\ NOT\ EXISTS\ plpgsql|COMMENT\ ON\ EXTENSION\ plpgsql)' > mydump.sql

Напевно, ви можете сміливо ігнорувати повідомлення про помилки в цьому випадку. Якщо не додати коментар до загальнодоступної схеми та встановлення plpgsql (який уже слід встановити), це не спричинить справжніх проблем.

Однак якщо ви хочете зробити повну перевстановку, вам знадобиться користувач з відповідними дозволами. Це, звичайно, не повинен бути користувачем, який, звичайно, запускає ваша програма.

Коротша відповідь: ігноруйте це.

Цей модуль є частиною Postgres, яка обробляє мову SQL. Помилка часто з’являється як частина копіювання віддаленої бази даних, наприклад, з 'heroku pg: pull'. Він не перезаписує ваш SQL-процесор і попереджає про це.

Спробуйте використати -Lпрапор з pg_restore, вказавши файл, взятий зpg_dump -Fc

-L list-file --use-list = список-файл

Відновіть лише ті елементи архіву, які вказані у списку-файлах, і відновіть їх у порядку, який вони відображаються у файлі. Зауважте, що якщо перемикачі фільтрації, такі як -n або -t, використовуються з -L, вони додатково обмежать відновлені елементи.

list-файл зазвичай створюється шляхом редагування результатів попередньої операції -l. Рядки можна переміщувати або видаляти, а також їх можна коментувати, розміщуючи крапку з комою (;) на початку рядка. Див. Приклади нижче.

https://www.postgresql.org/docs/9.5/app-pgrestore.html

pg_dump -Fc -f pg.dump db_name
pg_restore -l pg.dump | grep -v 'COMMENT - EXTENSION' > pg_restore.list
pg_restore -L pg_restore.list pg.dump

Тут ви можете бачити, що обернена правда, вивівши лише коментар:

pg_dump -Fc -f pg.dump db_name
pg_restore -l pg.dump | grep 'COMMENT - EXTENSION' > pg_restore_inverse.list
pg_restore -L pg_restore_inverse.list pg.dump
--
-- PostgreSQL database dump
--

-- Dumped from database version 9.4.15
-- Dumped by pg_dump version 9.5.14

SET statement_timeout = 0;
SET lock_timeout = 0;
SET client_encoding = 'UTF8';
SET standard_conforming_strings = on;
SELECT pg_catalog.set_config('search_path', '', false);
SET check_function_bodies = false;
SET client_min_messages = warning;
SET row_security = off;

--
-- Name: EXTENSION plpgsql; Type: COMMENT; Schema: -; Owner: 
--

COMMENT ON EXTENSION plpgsql IS 'PL/pgSQL procedural language';


--
-- PostgreSQL database dump complete
--

Для людей, які використовують AWS , цей модульCOMMENT ON EXTENSION можливий лише як суперпользователь файл , і, як ми знаємо за документами, екземплярами RDS керує Amazon. Таким чином, щоб запобігти вам порушити такі речі, як реплікація, ваші користувачі - навіть кореневий користувач, якого ви створили під час створення екземпляра - не матимуть повних привілеїв суперпользователя:

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.html

Коли ви створюєте екземпляр DB, основний обліковий запис користувача, який ви створюєте, присвоюється ролі rds_superuser. Роль rds_superuser - це заздалегідь визначена роль RDS Amazon, подібна до ролі суперрузера PostgreSQL (звичайно названі поштові адреси в локальних екземплярах), але з деякими обмеженнями. Як і у випадку надгрупової ролі PostgreSQL, роль rds_superuser має найбільше привілеїв у вашому екземплярі DB, і ви не повинні призначати цю роль користувачам, якщо їм не потрібен найбільший доступ до екземпляра БД.

Щоб виправити цю помилку, просто використовуйте --для коментування рядків SQL, які містятьCOMMENT ON EXTENSION

Використовуйте користувач postgres (admin) для скидання схеми, відтворення її та надання привілей для використання до відновлення. В одній команді:

sudo -u postgres psql -c "DROP SCHEMA public CASCADE;
create SCHEMA public;
grant usage on schema public to public;
grant create on schema public to public;" myDBName

Для мене я налаштовував базу даних з pgAdmin, і, здається, встановлення власника під час створення бази даних було недостатньо. Мені довелося перейти до схеми "public" і встановити там власника (спочатку "postgres").

Для людей, які звузили питання до COMMENT ONвисловлювань (відповідно до різних відповідей нижче) та які мають надрукований доступ до вихідної бази даних, з якої створений файл дампа, найпростішим рішенням може бути запобігання включенню коментарів до дампа файл, в першу чергу, видаляючи їх із вихідної бази даних, що скидається ...

COMMENT ON EXTENSION postgis IS NULL;
COMMENT ON EXTENSION plpgsql IS NULL;
COMMENT ON SCHEMA public IS NULL;

Майбутні звалища тоді не включатимуть COMMENT ONзаяви.