Tout récemment mon postgreSQL 8.2.4 enregistre de telles erreurs: L'erreur est toujours causée par le même scénario: une mise à jour du tableau A provoque le déclenchement, qui insère des données à la table. B, qui incendie un autre déclencheur, qui (parmi d'autres choses) sélectionne sur la table C. qui sélectionne sur le tableau C est ensuite signalé comme contexte du problème ci-dessus. La séquence de requêtes qui provoque l'apparition du message d'erreur est exécutée chaque jour et que tous les jours se plaint à peu près le même OID manquant. Tout naturellement, l'OID mentionné dans un message d'erreur n'existe pas lors de la requête PG_CLASS. Exécution de SQL problématique (c'est-à-dire, sélectionnez sur le tableau C) ne pose aucun problème. J'ai essayé de comprendre les OID et les connexions entre toutes les tables impliquées, pour déterminer où cette référence à une OID inexistante est, mais j'ai échoué. J'ai commencé avec la table A et obtenu son OID (pg_class.reltype) et vérifié, qu'il a une gâchette attachée. Les problèmes commencent lorsque je requête pg_trigger à l'aide de pg_trigger.tgrelid = pg_class.reltype comme une condition. La requête Yelds 0 rangées, mais quand je requête des tables juste par rel nommé / Tgname, je reçois différents OID, tout comme la gâchette est sur une table différente. J'ai fait un test rapide et il apparaît que la création d'une table simple avec une gâchette sur elle produit le même résultat. Donc, mes questions sont les suivantes: Comment naviguer dans pg_trigger (et d'autres tables PG comme pg_attribute, pg_shdepend) des tables quand je peux localiser la table dans pg_class?
Si d'une manière ou d'une autre, je parviens à trouver une référence à la problématique OID, suis-je sans danger pour supprimer la référence en effectuant des mises à jour directes / supprimées sur des tables pg_class?
3 Réponses :
Notez que 'ReltType' est l'OID de la table Rowtype - l'OID de la table elle-même est Espérons que cela résoudra des mystères de la manière dont les tables de catalogue se rapportent les unes aux autres! Le même motif est répété avec plusieurs autres tables en utilisant OID comme clé primaire.
Cela ressemble à un problème assez grave, indiquant éventuellement une sorte de corruption de catalogue? Vous pouvez modifier pg_class.oid (qui est une colonne système, donc ne figure pas dans \ d ou Sélectionnez la sortie * , vous devez le sélectionner explicitement).
pg_class et al directement, mais il y a évidemment des risques liés à cela. Je ne peux pas penser à beaucoup de conseils génériques pour donner ici ... Que faire variera grandement en fonction de ce que vous trouvez.
C'est exactement ce dont j'avais besoin. Après tout, le problème s'est tourné vers la trival. L'une des fonctions dépendait de la table qu'il y a quelque temps a été supprimée et recréée. En quelque sorte cette fonction utilisait OID de table qui a été supprimée. Il suffit de recréer une fonction et de la gâchette (les obligeant à obtenir le CURRY OID) résolue le problème.
Si cela apparaît lors de l'exécution des instructions à l'intérieur de la fonction SQL, modifiez la langue de SQL en PLPGSQL. La cause peut être un plan mis en cache. La fonction PLPGSQL invalide le plan entre les exécutions, tandis que la fonction SQL semble ignorer cette étape.
Vérifiez vos tables à Backend, PostgreSQL attribue une offre unique Essayez d'insérer des données à la base de données, puis faites-la via l'application.
Je faisais face au même problème et je me suis lutté longtemps.
La version 8.2.4 est très ancienne et dépassée, vous êtes (en ce moment) 16 rounds de patch derrière: 8.2.20 est le dernier. C'est 4 ans sans aucun entretien ... Digg dans toutes les notes de publication pour voir si ce problème a été corrigé.