Vous n'êtes pas identifié(e).
Bonjour à tous,
J'utilise debezium et donc la replication logique et je suis récemment tombé sur cette erreur qui fait planter l'utilisation de cet outil.
Cette erreur est intervenu à l'init dans une BDD et dans une autre, elle est intervenue après 1 mois d'utilisation de l'outil
ERROR: could not open toast relation with OID 0 (base relation "my_table")my_table =>
id | bigint | not null
blob | oid | not null
J'utilise PostgreSQL 12.12 , des LO se trouvent dans ma BDD et la table my_table ci dessus ne fait pas partie d'une publication
Donc debezium qui est un outil de change data capture n'est pas censé obtenir ces changements.
Auriez-vous une idée du problème ? est il possible de le résoudre ?
Merci d'avance
Hors ligne
C'est étrange, cette erreur provient du décodage logique. Il semblerait que lors du décodate postgres voit une modification dans une colonne toastée mais votre table n'a pas de relation toast associée, ce qui finit avec l'erreur que vous rencontrez.
Quelle est la définition complète de la table ?
Julien.
https://rjuju.github.io/
Hors ligne
Hello !
Merci d'avoir pris la peine de répondre
Voici plus de détail de la table:
id | bigint | | not null | | plain |
blob | oid | | not null | | plain |
Index :
"lob_pkey" PRIMARY KEY, btree (id)
Triggers :
lob_lo_unlink AFTER DELETE ON my_table FOR EACH ROW EXECUTE FUNCTION delete_lo()
lob_ro_access AFTER INSERT OR UPDATE ON my_table FOR EACH ROW EXECUTE FUNCTION grant_lob_access_to_ro()Merci
Hors ligne
La fonction grant_lob_access_to_ro exécute:
UPDATE pg_largeobject_metadata
SET lomacl ='{user=rw........}'
WHERE oid = NEW.blob;
RETURN NEW; Hors ligne
Il n'y a vraiment que 2 colonnes ? Même s'il y avait un problème du côté du décodage logique, la table pg_largeobject_metadata n'a pas de table TOAST non plus donc je vois mal comment le trigger pourrait être responsable. Au passage, pourquoi effectuer du DML sur pg_largeobject_metadata plutôt qu'utiliser GRANT SELECT/UPDATE ON LARGE OBJECT loid TO ...? Un UPDATE n'est pas officiellement supporté et peut poser des soucis.
Julien.
https://rjuju.github.io/
Hors ligne
Hello !!
Je pense avoir trouvé d'ou vient le problème
SELECT reltoastrelid FROM pg_class WHERE relname = 'pg_largeobject';
reltoastrelid
---------------
16637Ceci doit s'expliquer du fait d'un changement de tablespace de la table pg_largeobject (vrai ou pas ?)
Avez vous une solution qui pourrait reproduire cette solution
UPDATE pg_class
SET reltoastrelid = 0
WHERE relname = 'pg_largeobject';OU bien dois je restorer la base via dump ????
Merci
Dernière modification par Indaa (18/11/2022 13:36:45)
Hors ligne
Impossible à dire sans savoir ce que vous avez fait exactement, étant donné qu'il n'est normalement pas possible de changer le tablespace pour pg_largeobject.
Mais à priori oui, vous êtes bon pour devoir faire un export logique et réimporter les données.
Julien.
https://rjuju.github.io/
Hors ligne