Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Nous sommes en train de tester un ugrade d'une base 9.6 en 14.
La méthode utilisée est un pg_upgrade en mode link.
Lors de l'upgrade nous avons le message suivant sur la révocation de droits pour une fonction.
pg_restore: creating ACL "public.FUNCTION "versioning"()"
pg_restore: while PROCESSING TOC:
pg_restore: from TOC entry 1740606; 0 0 ACL FUNCTION "versioning"() postgres
pg_restore: error: could not execute query: ERROR: role "16390" does not exist
Command was: SELECT pg_catalog.binary_upgrade_set_record_init_privs(true);
REVOKE ALL ON FUNCTION "public"."versioning"() FROM PUBLIC;
REVOKE ALL ON FUNCTION "public"."versioning"() FROM "postgres";
SET SESSION AUTHORIZATION "16390";
GRANT ALL ON FUNCTION "public"."versioning"() TO "16390";
RESET SESSION AUTHORIZATION;
SELECT pg_catalog.binary_upgrade_set_record_init_privs(false);
REVOKE ALL ON FUNCTION "public"."versioning"() FROM "16390";
Il cherche un utilisateur "16390" qui bien sûr n'existe pas. J'avoue que je ne comprends pas bien d'où peut bien venir cette erreur.
Merci de votre aide.
Dernière modification par pitpoule (04/10/2022 09:43:17)
Hors ligne
Bonjour,
Vous avez à priori un problème sur votre instance 9.6. Que renvoie « SELECT oid, proname, proacl FROM pg_proc WHERE proname = 'versioning'; » sur l'instance source, sur la base où ce problème arrive.
Julien.
https://rjuju.github.io/
Hors ligne
lengow=> SELECT oid, proname, proacl FROM pg_proc WHERE proname = 'versioning';
oid | proname | proacl
-------+------------+-----------------------------------------------------------------------------------
17072 | versioning | {postgres=X/postgres,toto=X/postgres,toto_ro=X/postgres,toto_rw=X/postgres}
(1 row)
Time: 0.624 ms
Je ne sais pas quelle info vous avez besoin mais les utilisateurs toto* sont valides.
Hors ligne
Je ne sais pas quelle info vous avez besoin mais les utilisateurs toto* sont valides.
Je cherche l'entrée dans le catalogue référençant un utilisateur qui a été supprimé, cd qui devrait être la cause de votre problème. La commande suivante:
pg_dump --schema-only --quote-all-identifiers --binary-upgrade --dbname $nomdelabase | grep versioning -A10
devrait afficher l'ordre REVOKE problématique (et donc confirmer que le problème bien bien de l'instance et base source).
S'agit-il d'une fonction créée dans une extension?
Avez-vous des lignes dans pg_extension où extowner vaut 16390 ? Ou des lignes dans pg_init_privs où initprivs contient 16390 ?
Julien.
https://rjuju.github.io/
Hors ligne
On a bien une ligne dans le pg_init_privs contient une ligne référençant cet "user".
Après une petite enquête de notre côté, il semble qu'un user a été droppé et que des tables systèmes ont été mises à jour manuellement pour ne pas avoir à drop/create l'extension utilisant la fonction versioning.
Honnêtement, ça va être très compliqué de drop/create l'extension pour remettre en état car elle est utilisée dans des 10aines de milliers de tables. Est ce que l'on peut envisager de remodifier les tables systèmes (notamment pg_init_privs) pour retomber sur nos jambes ?
En tout cas, merci pour votre aide
Hors ligne
J'imagine que cet utilisateur était le propriétaire de l'extension ?
Y a-t-il une raison pour ne pas avoir utilisé REASSIGN OWNED ? (https://www.postgresql.org/docs/current/sql-reassign-owned.html ). Mais effectivement, maintenant que votre catalogue est corrompu vous n'avez pas d'autre choix qu'essayer de réparer manuellement les catalogues. Impossible de dire si vous n'avez pas déjà de problèmes invisibles (types autorisation en trop de que vous devriez avoir etc), ni si la modification manuelle du catalogue permettra de vraiment tout corriger mais cela devrait au moins vous permettre d'effectuer la mise à jour.
Vous devriez essayer d'utiliser https://github.com/EnterpriseDB/pg_catcheck, cet outil devrait vous aider à trouver tous les problèmes liés aux modifications du catalogue.
Julien.
https://rjuju.github.io/
Hors ligne
J'imagine que cet utilisateur était le propriétaire de l'extension ?
Je n'ai pas tout l'historique que mais je suppose que c'est ça
Y a-t-il une raison pour ne pas avoir utilisé REASSIGN OWNED ? (https://www.postgresql.org/docs/current/sql-reassign-owned.html ). Mais effectivement, maintenant que votre catalogue est corrompu vous n'avez pas d'autre choix qu'essayer de réparer manuellement les catalogues. Impossible de dire si vous n'avez pas déjà de problèmes invisibles (types autorisation en trop de que vous devriez avoir etc), ni si la modification manuelle du catalogue permettra de vraiment tout corriger mais cela devrait au moins vous permettre d'effectuer la mise à jour.
Une méconnaissance de la commande je suppose. On va tenter l'update manuel pour arriver à faire l'upgrade
Vous devriez essayer d'utiliser https://github.com/EnterpriseDB/pg_catcheck, cet outil devrait vous aider à trouver tous les problèmes liés aux modifications du catalogue.
Merci pour l'outil, on va tester
Hors ligne
Pages : 1