Vous n'êtes pas identifié(e).
Pages : 1
En effet, mais je n'ai pas trouvé comment préciser un pg_dump.
En revanche, j'ai découvert SQL Manager Studio qui m'a permis de faire un backup / restore propre, car il demande la version désirée
Merci en tout cas pour toute vos réponses.
Henry
Merci de votre réponse,
mais faire "CREATE PROCEDURAL LANGUAGE plpgsql" fonctionne : Manifestement, c'est le "OR REPLACE" qui pose problème !
Or, c'est une fonctionnalité qui a été ajouté pour Postgresql 9, je vais essayer une vieille version de pgadmin
PS : La base de restauration est une base de prod ...
Bonjour,
J'essaye de faire un backup/restore d'une base vers une autre, les 2 étant 8.3, avec pgadmin (dont j'ai essayé plusieurs versions)
j'ai un fichier backup qui me génère l'erreur suivante :
pg_restore: connecting to database for restore
pg_restore: creating SCHEMA cache
pg_restore: creating SCHEMA caching
pg_restore: creating SCHEMA community
pg_restore: creating COMMENT SCHEMA community
...
pg_restore: creating PROCEDURAL LANGUAGE plpgsql
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 1046; 2612 16386 PROCEDURAL LANGUAGE plpgsql postgres
pg_restore: [archiver (db)] could not execute query: ERREUR: erreur de syntaxe sur ou près de « PROCEDURAL »
évidement, toutes les fonctions en plpgsql ne sont pas restaurées ...
Ce qui est étrange c'est que je n'ai pas l'erreur avec des backups de base dont la structure est identique ...
Si quelqu'un avait une petite idée de ce qui peut poser problème, ce serait super !
Merci
Henry
Fantastique, ça marche !
je vois bien tout l'intérêt de ce type de fonction pour ce genre d'opération
Merci de m'avoir répondu aussi vite ...
Henry
Bonjour,
Je m'excuse si j'aurais mieux fait de mettre ce post dans la partie "optimisation", mais il m'a semblé qu'il s'agissait plutôt d'un problème général au sujet de truncate, ou globalement d'une réécriture de table.
je dois faire une requête qui nécessite des jointure avec une vue, et ceci fréquemment. (vérification de liens entre articles de contrats)
La vue est en elle même assez complexe et a beaucoup de lignes. L'opération était donc super longue ...
J'ai donc fait une table "cache", dans la quelle je copie le contenu de ma vue, et tout va très vite ...
Je n'ai à la "mettre à jour" que lorsqu'on insère de nouveaux liens (ce qui modifie en effet la vue), ce qui est beaucoup plus rare que la consultation.
Pour la mise à jour, j'ai une fonction qui doit faire un truncate puis un insert into [cache] (select * from [ma vue])
Oui mais je ne peux pas faire de truncate, si je ne suis pas l'owner de la table, ce qui n'est jamais le cas dans l'appli, et celle-ci contient 3 index de clés étrangères.
J'ai peur qu'en me contentant d'un delete from puis de l'insert, ma table va exploser l'espace disque, à moins qu'un autovacuum ...
Y-a-t-il une méthode pour éviter ce genre de problèmes avec truncate ou pour gérer des table qui doivent être souvent et intégralement réécrites ???
Merci beaucoup
Henry
Pages : 1
