PostgreSQL 9.1 pg_restore erreur concernant PLPGSQL
J'utilise Postgres pour un projet django et je suis actuellement à la mise en œuvre d'une base de données de sauvegarde/restauration système aussi simple que possible effectue un pg_dump lorsque l'utilisateur clique sur sauvegarde, puis pg_restore quand ils cliquez sur restaurer la sauvegarde.
Tout semble aller bien dans le meilleur des mondes jusqu'à ce qu'il tente d'effectuer les pg_restore à laquelle il donne cette erreur:
pg_restore: [archiver (db)] Erreur à partir de l'entrée de table des matières 3206; 0 0 COMMENTAIRE
EXTENSION plpgsql pg_restore: [archiver (db)] impossible d'exécuter la requête:
ERREUR: vous devez être propriétaire de l'extension de plpgsql Commande était: COMMENTAIRE SUR
EXTENSION plpgsql EST 'PL/pgSQL langue de la procédure';
J'ai regardé dans ce plpgsql est etc, et je le comprends, et concernant l'erreur que j'ai essayé de régler manuellement le "propriétaire de l'extension" à l'utilisateur qui exécute le script et propriétaire de la base de données elle-même, mais cela n'a rien changé, c'est vraiment gênant depuis sa erroring sur une tentative de mettre un commentaire de toutes les choses
Tout ceci est créé automatiquement par pg_dump de sorte que la ligne de commentaire ne peut pas être supprimé et il n'existe pas d'option pour désactiver les commentaires (que je suis au courant), donc je suis vraiment coincé comme à la façon de résoudre ce problème.
- Si vous vous connectez à l'aide de psql et le type
\l
, que voyez-vous dans le "Propriétaire" de la colonne de la base de données? Depuis plpgsql est pas de confiance de la langue, elle ne peut être modifiée (et je pense que s'applique même à le commenter) par le propriétaire de base de données ou une base de données de super-utilisateur. - je peux confirmer que le propriétaire de la base de données est correcte et correspond à l'utilisateur spécifié par l'option-U de la pg_restor de commande (et le pg_dump trop)
- Ce n'est pas aussi simple que cela, malheureusement. J'ai pg_dump de sortie qui s'attend à être en mesure de créer des langues et des fonctions à l'aide de ces langues. Si j'ai la main-créer de la langue comme la bd de super-utilisateur, la fonction de création échoue en raison d'erreurs de permission. Si je ne le fais pas, la langue de la procédure d'installation échoue en raison d'erreurs de permission. Dans les deux cas, déclenche plus bas qui s'appuient sur les fonctions existantes, aussi ne peut pas être créé, parce que les fonctions n'existent pas.
Vous devez vous connecter pour publier un commentaire.
Il semble que pg_restore tente de restaurer des données supplémentaires qui ne vous appartient pas. Essayez d'ajouter
-n public
option pour votre pg_restore ligne de commande. Il dira pg_restore restaurer uniquement le contenu du schéma public. Votre ligne de commande devrait ressembler àpg_restore
essayer de charger des extensions supplémentaires, qui, dans notre scénario, il n'était pas autorisée.J'ai trouvé la solution de contournement suivante sur cette page:
http://archives.postgresql.org/pgsql-general/2011-10/msg00826.php
L'idée est d'utiliser pg_restore -l pour lister le contenu de l'archive, grep l'extension que l'utilisateur n'est pas autorisé à restaurer, et l'utilisation pg_restore -L pour utiliser cette élidés liste lors de la restauration.
Par exemple:
STDOUT
de sorte que vous aurez probablement envie de le rediriger vers un fichier à la place.Si possible, je vous recommande de supprimer les commentaires qui ne parvient pas à restaurer avant de créer des décharges.
Vous pouvez le faire par:
Si vous ne voulez pas faire cela pour chaque base de données nouvellement créée, supprimez le commentaire de la DB appelé template1 (
CREATE DATABASE…
des copies de cette base de données.)Décharges créé après que devrait restituer avec aucune erreur.
Êtes-vous de le charger dans une base de données qui a été créé par un autre utilisateur? Si possible, essayez de restauration en utilisant le même utilisateur qui a créé la base de données et ses objets existants.
Fonctionne pour moi après cette commande
Si vous êtes en cours d'exécution Postgres 11 (ou plus) de la version de
pg_dump
, alors vous pouvez prendre avantage de la nouvelle--no-comments
drapeau.