Vous n'êtes pas identifié(e).
Pages : 1
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
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
Bonjour,
j'ai une instance master (master1) qui replique physiquement (en streaming replication) sur un slave . J'ai aussi un autre master (master 2) qui replique logiquement (en streaming replication) ses tables du schema (schema1) sur le 1er master (master 1).
En cas d'arrêt du master1 je (ou automatiquement avec PAF ou repmgr) promote le slave en master3 .
J'aimerai switcher la replication logique du master2 vers le master3 sans avoir à truncater les tables du schema1 du master 3 (car les données sont à jour du fait de la réplication physique) et refaire la descente des données .
Ect-ce possible de dupliquer ou modifier le slot de replication du master2 pour le faire pointer sur le master3 et n'avoir aucune données à redescendre et reprendre le flux de replication logique ?
Environnement : version postgresql 11. 2 sur une vm en redhat 7.4
Merci
Bonjour,
Nous aimerions utiliser la fonctionnalité d'héritage pour une RDO mais celle-ci semble inexploitable.
En effet On ne peut pas utiliser des contraintes d'intégrité sur la table parente si l'enregistrement a été crée sur une base fille de ce parent.
Un sujet à priori connu depuis longtemps.
http://geekblog.over-blog.com/article-17775481.html
Y a t-il un moyen de contournement ? Ce sujet est-il abandonné ou dans la roadmap de postgres ?
Merci
Pages : 1
