Forums PostgreSQL.fr

Bonjour,
J'ai une réplication logique entre une base postgresql en version 11.22 sur os ubuntu 22.04 LTS  et une base abonnée  en pg17.7 sur Goggle Cloud Platform . J'ai 333 tables à répliquer mais aucune ne se réplique car  le max_replication_slot qui est sétté  à 10 sur le publieur n'est pas assez haut . le max_sync_workers_per_subscription sur l'abonné est pourtant à 2 (Sur GCP on ne peut pas baisser à moins de 2) .
Voici l'état des slots de replication sur le publieur
[local]:6095 postgres@scapnor=# select slot_name,active FROM pg_replication_slots;
                slot_name                 | active
------------------------------------------+--------
repmgr_slot_2                            | t
rebuild_infoprod_scapnor_20250602_1117   | t
gcp_scapnorbi                            | t
pg_161210_sync_17519_7571794086042918928 | f
pg_161210_sync_17525_7571794086042918928 | f
pg_161210_sync_17568_7571794086042918928 | f
pg_161210_sync_17580_7571794086042918928 | f
pg_161210_sync_17586_7571794086042918928 | f
pg_161210_sync_17639_7571794086042918928 | f
pg_161210_sync_17645_7571794086042918928 | f
(10 lignes)

il y a 3  slots qui sont actifs (standby + un infocentre + la souscription vers GCP initiale)   + 7 slots de synchro inactifs 

Voici la commande de creation de souscription
CREATE SUBSCRIPTION gcp_scapnorbi  CONNECTION 'host=10.72.0.115 port=60000  user=datastream  password=********* dbname=scapnor' publication scapnor_gcp_bigquery;

Quand je regarde les logs GCP la souscription essaye de lancer 329 tables différentes (started ) sur les 333 comme si le paramètre max_sync_workers_per_subscription  n'etait pas pris en compte alors qu'il est à 2 sur GCP  . Aucun statut 'finished' dans les logs GCP, aucune table n'est répliquée et le process de réplication tourne à l'infini avec ces messages started depuis l'abonné et le message 'increase max_replication_slot' depusi le publieur . Si je detruit les slots inactif il en regénère d'autres dans la foulée qui sont inactifs.

Sur l'abonné.
scapnorbi=> show max_sync_workers_per_subscription ;
max_sync_workers_per_subscription
-----------------------------------
2
(1 row)

Si je change de publieur avec la même version pg je n'ai pas ce problème .

A part agrandir le max_replication slots (et de combien ?) que puis-je faire pour que la réplication démarre ?
merci

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,

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