PostgreSQL 9.1 pg_restore Fehler bezüglich PLPGSQL

73

Ich verwende Postgres für ein Django-Projekt und implementiere derzeit ein Datenbanksicherungs- / Wiederherstellungssystem, das so einfach wie möglich einen pg_dump ausführt, wenn der Benutzer auf Backup klickt, und dann pg_restore, wenn er auf Backup wiederherstellen klickt.

Alles scheint in Ordnung und gut zu sein, bis es tatsächlich versucht, den pg_restore auszuführen. Zu diesem Zeitpunkt gibt es diesen Fehler:

pg_restore: [archiver (db)] Fehler vom Inhaltsverzeichniseintrag 3206; 0 0 COMMENT EXTENSION plpgsql pg_restore: [archiver (db)] konnte keine Abfrage ausführen: ERROR: muss Eigentümer der Erweiterung sein plpgsql Befehl war: COMMENT ON EXTENSION plpgsql IS 'PL / pgSQL-Prozedurensprache';

Ich habe mir angesehen, was plpgsql usw. ist, und ich verstehe das. In Bezug auf den Fehler habe ich versucht, den "Eigentümer der Erweiterung" manuell auf den Benutzer festzulegen, der das Skript ausführt und die Datenbank selbst besitzt, aber das hat nichts geändert, was seitdem wirklich ärgerlich ist Es ist ein Fehler bei dem Versuch, einen Kommentar zu allen Dingen abzugeben

Dies alles wird automatisch von pg_dump erstellt, sodass die Kommentarzeile nicht entfernt werden kann und es keine Flags zum Deaktivieren von Kommentaren gibt (von denen ich weiß, dass sie deaktiviert sind). Daher bin ich wirklich festgefahren, wie dieses Problem gelöst werden kann.

postgresql plpgsql database-restore

— Wut-s12
quelle

Wenn Sie eine Verbindung mit psql herstellen und eingeben \l, was sehen Sie in der Spalte "Eigentümer" für diese Datenbank? Da plpgsql eine nicht vertrauenswürdige Sprache ist, kann sie nur vom Datenbankeigentümer oder einem Datenbank-Superuser geändert werden (und ich würde vermuten, dass dies auch für den Kommentar gilt).

— kgrittn

Ich kann bestätigen, dass der Eigentümer der Datenbank korrekt ist und mit dem Benutzer übereinstimmt, der durch die Option -U des Befehls pg_restor (und auch durch den Befehl pg_dump) angegeben wurde

— fury-s12

So einfach ist das leider nicht. Ich habe eine pg_dump-Ausgabe, die erwartet, Sprachen und Funktionen mit diesen Sprachen erstellen zu können. Wenn ich die Sprache als DB-Superuser von Hand erstelle, schlägt die Funktionserstellung aufgrund von Berechtigungsfehlern fehl. Wenn dies nicht der Fall ist, schlägt die Installation der prozeduralen Sprache aufgrund von Berechtigungsfehlern fehl. In beiden Fällen können Trigger, die sich auf die vorhandenen Funktionen stützen, ebenfalls nicht erstellt werden, da die Funktionen nicht vorhanden sind.

— Quixadhal

123

Es scheint, als ob pg_restore versucht, einige zusätzliche Daten wiederherzustellen, die Sie nicht besitzen. Versuchen Sie -n public, Ihrer pg_restore-Befehlszeile eine Option hinzuzufügen . Es wird pg_restore mitteilen, dass nur Inhalte des öffentlichen Schemas wiederhergestellt werden. Ihre Befehlszeile sollte so aussehen

pg_restore -U username -c -n public -d database_name

— Roman Akinfold
quelle

9

Enthält diese Option einen Informationsverlust nach der Wiederherstellung? Das heißt, werden wichtige Daten verloren gehen?

— C2H5OH

8

@ C2H5OH es kommt darauf an. Wenn Ihre Datenbanksicherung mehr als ein Schema enthält, importiert der obige Befehl nur das Schema "public" (= Informationsverlust). Wenn Ihr Dump nur das Schema "public" enthält, liegt kein Problem vor (siehe: pg_dump --exclude-schema). Um zu überprüfen, welche Schemas in Ihrer Dump-Datei enthalten sind, führen Sie Folgendes aus: pg_restore -l -F t dumpfile.tar | grep SCHEMA | awk -F "" '{print $ (NF-1)}' -

— DanielaWaranie

2

Dies hat mein Problem mit dem pg_restoreVersuch behoben, zusätzliche Erweiterungen zu laden, was in unserem Szenario nicht erlaubt war.

— Nibbex

2

Sie müssen auch vorsichtig sein, wenn Sie große Objekte verwenden, diese werden nicht wiederhergestellt

— Peter Gerber

18

Ich habe auf dieser Seite die folgende Problemumgehung gefunden:

http://archives.postgresql.org/pgsql-general/2011-10/msg00826.php

Die Idee ist, pg_restore -l zu verwenden, um den Inhalt des Archivs aufzulisten, die Erweiterung zu ermitteln, für deren Wiederherstellung der Benutzer keine Berechtigung hat, und pg_restore -L zu verwenden, um diese elidierte Liste beim Wiederherstellen zu verwenden.

Zum Beispiel:

pg_restore -l ~/database.dump | grep -v "EXTENSION - plpgsql" > ~/restore_elements
pg_restore -L ~/restore_elements ~/database.dump

— schimpfen
quelle

2

Das hat bei mir funktioniert. Eine Warnung, der zweite Befehl druckt alles aus, STDOUTsodass Sie es wahrscheinlich stattdessen in eine Datei umleiten möchten.

— Shrx

Gibt es eine Möglichkeit, dies mit nur einem Befehl zu tun? Ich habe einen automatisierten Prozess und das wird nicht funktionieren.

— Diego

7

Wenn möglich, empfehle ich, den Kommentar zu entfernen, der nicht wiederhergestellt werden kann, bevor Dumps erstellt werden.

Sie können dies tun durch:

COMMENT ON EXTENSION plpgsql IS null;

Wenn Sie dies nicht für jede neu erstellte Datenbank tun möchten, entfernen Sie den Kommentar aus der Datenbank mit dem Namen template1 ( CREATE DATABASE…kopiert diese Datenbank.)

Danach erstellte Dumps sollten fehlerfrei wiederhergestellt werden.

— Peter Gerber
quelle

6

Wenn Sie die Version von Postgres 11 (oder höher) ausführenpg_dump , können Sie die neue --no-commentsFlagge nutzen.

— jabclab
quelle

3

Laden Sie in eine Datenbank, die von einem anderen Benutzer erstellt wurde? Versuchen Sie nach Möglichkeit, die Wiederherstellung mit demselben Benutzer durchzuführen, der die Datenbank und ihre vorhandenen Objekte erstellt hat.

— Edmund
quelle

Nein, alles wird mit dem Flag "-U Benutzername" als derselbe Benutzer aufgerufen, nur um sicherzugehen

— Fury-S12

3

Funktioniert für mich nach diesem Befehl -

Deepak@deepak:~$ sudo -i -u postgres
postgres@deepak:~$ psql 
psql (9.3.5)
Type "help" for help.

postgres=# GRANT ALL PRIVILEGES ON DATABASE database_name TO user;
postgres=# GRANT

— Deepak Mahakale
quelle