PostgreSQL La base de donnees la plus sophistiquee au monde.

Forums PostgreSQL.fr

Le forum officiel de la communauté francophone de PostgreSQL

Vous n'êtes pas identifié(e).

#1 05/07/2021 14:00:32

debellabre
Membre

Pg_dump en erreur (Version 11.12 sur redhat 7.4 / Vmware 6.5)

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

#2 05/07/2021 16:37:06

gleu
Administrateur

Re : Pg_dump en erreur (Version 11.12 sur redhat 7.4 / Vmware 6.5)

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

#3 05/07/2021 16:43:04

dverite
Membre

Re : Pg_dump en erreur (Version 11.12 sur redhat 7.4 / Vmware 6.5)

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}');

Hors ligne

#4 06/07/2021 09:07:25

debellabre
Membre

Re : Pg_dump en erreur (Version 11.12 sur redhat 7.4 / Vmware 6.5)

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

#5 06/07/2021 09:43:34

gleu
Administrateur

Re : Pg_dump en erreur (Version 11.12 sur redhat 7.4 / Vmware 6.5)

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

Pied de page des forums