Vous n'êtes pas identifié(e).
Bonjour
Un pg_dump ne se lance pas: pg_dump
pg_dump: le schéma d'OID 6072711 n'existe pas
A priori un schéma qui n'existe pas. J'ai eu plusieurs fois(3) cette erreur sur d'autres vm à la suite de multiples déploiements automatisés qui drop puis rec-cre des schémas avec ses tables.
Je n'ai pourtant pas de schéma manquant . C'est comme si des objets avaient été mal nettoyés lors du précédent drop.
Y a t-il une technique pour débugger le pg_dump et voir où est l'erreur pour repérer d'éventuels objets non detruits du schéma ?
Où il y a t-il une vue qui permettrait de repérer des traces de cet OID ?
La lecture des tables du dictionnaire n'a rien donnée
select * from pg_type where typnamespace=6072711;
select * from pg_class where relnamespace=6072711;
select * from pg_aggregate where aggfnoid = 6072711 or aggtransfn = 6072711 or aggfinalfn = 6072711;
select * from pg_proc where pronamespace = 6072711;
select * from pg_opclass where opcnamespace = 6072711;
select * from pg_conversion where connamespace = 6072711;
select * from pg_operator where oprnamespace = 6072711;
Merci
Hors ligne
A priori un schéma qui n'existe pas. J'ai eu plusieurs fois(3) cette erreur sur d'autres vm à la suite de multiples déploiements automatisés qui drop puis rec-cre des schémas avec ses tables.
Normalement, ça ne devrait jamais arriver donc il faudrait déjà comprendre comment vous en êtes arrivé là. Faites vous réellement un DROP du schéma ?
Y a t-il une technique pour débugger le pg_dump et voir où est l'erreur pour repérer d'éventuels objets non detruits du schéma ?
Je pense que le plus simple est de tracer toutes les requêtes émises par ce pg_dump, puis de rechercher les requêtes qui utilisent cet OID,et enfin de tester ces requêtes.
Où il y a t-il une vue qui permettrait de repérer des traces de cet OID ?
Non. Il faut chercher tous les catalogues qui peuvent contenir un namespace, et les requêter un à un.
Guillaume.
Hors ligne
Un raccourci serait peut-être de chercher 6072711 partout dans pg_catalog.
Personnellement j'utiliserais cette fonction:
https://github.com/dverite/postgresql-f … search.sql
qui sort les tables/colonnes dans lesquelles une valeur se trouve,
en l'appelant comme ça:
select * from global_search('6072711', '{}','{pg_catalog}');@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
Merci beaucoup pour vos réponses . La fonction global_search est impeccable . J'ai repéré les objets en trop puis les ai delet" . Le pg_dump fonctionne. Je pense que ce pgénomène arrive quand il ay des locks exclusif sur des drop cascade du schéma et qu'une personne kill le backend du drop au milieu. Comme cest du DDL j'imagine qu'il n'y a pas de rollback et que le drop cascade est commencé mais pas fini.
Voici le procédure de Daniel que j'ai déroulée :
select * from global_search('6072711', '{}','{pg_catalog}');
schemaname | tablename | columnname | rowctid
------------+----------------+-----------------+----------
pg_catalog | pg_depend | refobjid | (99,29)
pg_catalog | pg_depend | refobjid | (99,32)
pg_catalog | pg_depend | refobjid | (101,19)
pg_catalog | pg_depend | refobjid | (101,21)
pg_catalog | pg_depend | refobjid | (99,29)
pg_catalog | pg_depend | refobjid | (99,32)
pg_catalog | pg_depend | refobjid | (101,19)
pg_catalog | pg_depend | refobjid | (101,21)
pg_catalog | pg_default_acl | defaclnamespace | (0,50)
pg_catalog | pg_default_acl | defaclnamespace | (0,54)
pg_catalog | pg_default_acl | defaclnamespace | (0,73)
pg_catalog | pg_default_acl | defaclnamespace | (0,75)
pg_catalog | pg_default_acl | defaclnamespace | (0,50)
pg_catalog | pg_default_acl | defaclnamespace | (0,54)
pg_catalog | pg_default_acl | defaclnamespace | (0,73)
pg_catalog | pg_default_acl | defaclnamespace | (0,75)
(16 lignes)
select * from pg_default_acl where defaclnamespace=6072711;
defaclrole | defaclnamespace | defaclobjtype | defaclacl
------------+-----------------+---------------+------------------------------------------------------------------------------
16532 | 6072711 | r | {reader=r/fac_cff,delta=arwdDx/fac_cff}
10 | 6072711 | r | {ref_rco=r/postgres,alice_ro=r/postgres,ref_jde=r/postgres,delta=r/postgres}
10 | 6072711 | f | {ref_jde=X/postgres}
10 | 6072711 | S | {ref_rco=r/postgres,alice_ro=r/postgres,ref_jde=r/postgres,delta=r/postgres}
(4 lignes)
[local]:5432 postgres@tst=# delete from pg_default_acl where defaclnamespace=6072711;
DELETE 4
[local]:5432 postgres@tst=# select * from pg_depend where refobjid=6072711;
classid | objid | objsubid | refclassid | refobjid | refobjsubid | deptype
---------+---------+----------+------------+----------+-------------+---------
826 | 6114238 | 0 | 2615 | 6072711 | 0 | a
826 | 6114246 | 0 | 2615 | 6072711 | 0 | a
826 | 6114242 | 0 | 2615 | 6072711 | 0 | a
826 | 6114247 | 0 | 2615 | 6072711 | 0 | a
(4 lignes)
delete from pg_depend where refobjid=6072711;
DELETE 4
Le pg_dump a fontionné ausi avant le 2ème delete
Hors ligne
Comme cest du DDL j'imagine qu'il n'y a pas de rollback et que le drop cascade est commencé mais pas fini.
Totalement faux. Le DDL est tout à fait annulable. Le DDL fonctionne aussi dans des transactions.
delete from pg_default_acl where defaclnamespace=6072711;
delete from pg_depend where refobjid=6072711;
Je vous conseille très fortement de ne plus vous baser sur cette base. De la reconstruire. Sinon les ennuis ne font que commencer.
Je comprends le besoin de faire ces manips pour réaliser le pg_dump, mais cela vient d'un autre problème qu'il faudrait comprendre. En temps normal, il ne faut jamais faire de modifications directes (via des INSERT ou des DELETE) dans les catalogues systèmes).
Guillaume.
Hors ligne