Vous n'êtes pas identifié(e).
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
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
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 msJe ne sais pas quelle info vous avez besoin mais les utilisateurs toto* sont valides.
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.
Petit retour sur le sujet, l'augmentation du paramètre max_locks_per_transaction a fait disparaître l’apparition des messages dans le log.
Merci à tous pour votre aide
Merci pour le retour détaillé
pglogical est en version 2.3.1 . On doit avoir deux versions de retard sur la version courante, on n'a pas encore effectué la mise à jour car nous ne l'utilisons pas pour le moment.
Nous avons une maintenance de prévue dans quelques jours, nous allons en profiter pour augmenter la valeur du max_locks_per_transaction.
Merci pour vos conseils, je vais regarder ça pour une mise en place 
Sinon pour mon problème initial, le passage en verbose à rajouter un petit peu d'information...
2021-02-24 16:22:53 CET [61131]: [23-1] db=db1,user=user1,app=app1 - 127.0.0.1:27233 WARNING: 53200: out of shared memory
2021-02-24 16:22:53 CET [61131]: [24-1] db=db1,user=user1,app=app1 - 127.0.0.1:27233 LOCATION: ShmemAlloc, shmem.c:212J'aurais tendance à dire que c'est catastrophique. Vous pouvez regarder cet article pour plus de détail sur le problème et ses conséquences : https://rjuju.github.io/postgresqlfr/20 … ndues.html
Ah quand même.... est ce que si vm.nr_hugepages, il faut redémarrer le moteur PG ?
J'avais déjà lu votre article... fort intéressant d'ailleurs
Honnêtement, nous n'avons pas constaté des pertes de performances inexpliquées ou aléatoires... la moyenne des connexions à la base se situe entre 200 et 300, je dirais.
postgres$ for p in $(pgrep postgres); do grep "VmPTE:" /proc/$p/status; done | awk '{pte += $2} END {print pte / 1024}'
35009.735G, je ne saurais dire, si c'est peu ou beaucoup
Petit détail en apparté, mais avec la taille de votre shared_buffers et le nombre de connexions, il est assez crucial d'avoir les huge pages activées si vous avez des connexions persistentes et/ou un pooler de connexion, sans quoi vous risquez de gacher une quantité phénoménale de mémoire pour les PTE (page table entry) et d'avoir des problèmes de performances assez importants et aléatoires. Vous pouvez consulter la documentation à https://docs.postgresql.fr/9.6/runtime- … ource.html pour plus de détail.
Le paramètre vaut "try".
En regardant la doc PG, je vois ces valeurs pour les hugepages
postgres$ grep ^VmPeak /proc/64027/status
VmPeak: 103100328 kB
postgres$ grep ^Hugepagesize /proc/meminfo
Hugepagesize: 2048 kB
postgres$ grep Huge /proc/meminfo
AnonHugePages: 14336 kB
ShmemHugePages: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
Hugetlb: 0 kB C'est moi qui ne comprend pas bien mais j'ai l'impression qu'elles ne sont pas utilisées... est ce que c'est bien le cas ?
Merci pour le retour
Dans mon cas, on a le max_connections est à 1000 et je partirai sur un max_locks_per_transaction à 256, ce qui amène à 131Mo, je pense que ça reste raisonnable par rapport à la shared_buffers
bonjour,
un shared_buffers à 96G ? combien de RAM y a t'il sur votre serveur ?
et avez-vous des alertes mémoire au niveau de l'OS ?
le serveur possède 256G de RAM
La consommation de RAM est ok à chaque fois que les messages apparaissent
Merci ! Pouvez-vous également montrer le contenu de shared_preload_libraries?
Effectivement, verbose va ajouter au moins une ligne supplémentaire pour chaque occurence. Mais le paramètre est pour le moment bien configuré à default?.
Oui, il est bien à default.
postgres=# show shared_preload_libraries;
shared_preload_libraries
--------------------------
pglogical
(1 row)Je me souviens avoir eu à gérer des warnings de ce style sur une instance 9.6
La raison apparente était la même que les erreurs qui mènent au HINT "You might need to increase max_locks_per_transaction", c'est-à-dire que résoudre l'erreur supprime aussi les warningsmax_locks_per_transaction par défaut (64) est assez faible. Il suffit d'avoir une base avec des hiérarchies profondes avec éventuellement pas mal d'index et des requêtes dont le plan d'exécution va chercher toute la hiérarchie pour dépasser ou flirter avec la limite globale (max_locks_per_transaction * max_connections). Ou beaucoup de "large objects" utilisés dans une même transaction.
Je me suis fait la même réflexion... finalement, est ce qu'on n'est pas juste avant le déclenchement de l'erreur.
Est ce que max_locks_per_transaction peut être augmenté franchement ou bien faut il y aller en douceur ? Par exemple est ce que je peux le passer à 256 voir 512, d'entrée ?
Name | Version | Schema | Description
-----------------+---------+------------+-------------------------------------------------------------------
btree_gist | 1.2 | public | support for indexing common datatypes in GiST
hstore | 1.4 | public | data type for storing sets of (key, value) pairs
ip4r | 2.1 | public |
pageinspect | 1.5 | public | inspect the contents of database pages at a low level
pg_buffercache | 1.2 | public | examine the shared buffer cache
pg_freespacemap | 1.1 | public | examine the free space map (FSM)
pg_repack | 1.4.5 | public | Reorganize tables in PostgreSQL databases with minimal locks
pg_trgm | 1.3 | public | text similarity measurement and index searching based on trigrams
pg_visibility | 1.1 | public | examine the visibility map (VM) and page-level visibility info
pgcrypto | 1.3 | public | cryptographic functions
pglogical | 2.3.1 | pglogical | PostgreSQL Logical Replication
pgstattuple | 1.4 | public | show tuple-level statistics
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
plpython3u | 1.0 | pg_catalog | PL/Python3U untrusted procedural language
plpythonu | 1.0 | pg_catalog | PL/PythonU untrusted procedural language
pltcl | 1.0 | pg_catalog | PL/Tcl procedural language
postgres_fdw | 1.0 | public | foreign-data wrapper for remote PostgreSQL servers
temporal_tables | 1.1.0 | public | temporal tables
tsm_system_rows | 1.0 | public | TABLESAMPLE method which accepts number of rows as a limit
tsm_system_time | 1.0 | public | TABLESAMPLE method which accepts time in milliseconds as a limit
unaccent | 1.1 | public | text search dictionary that removes accents
url_encode | 1.2 | public | url_encode, url_decode functionsPour la verbosité des logs, je modifierai demain... on génère tellement de logs que j'ai peur que ça coince niveau disque
Info supplémentaire , les process
2021-02-23 07:37:00 CET [22600]: [1-1] db=,user=,app= WARNING: out of shared memory
ont l'air d'être des auto vacuum, ce qui me conforte dans l'idée que le problème est global
En remontant dans les rapports pgbadger, le message apparait depuis des mois. Certains jours, il n'y en a pas et d'autres quelques dizaines (à remettre en visu des 10aines de millions de requêtes/jour)
Le phénomène est global car cela concerne des connexions frontend comme backend. Ça arrive par "salve".
Malheureusement, je n'ai pas les requêtes associées. De ce que je vois aussi, ça arrive à des périodes de grosse activité côté traitements backend (backend applicatif, pas les backend PG).
021-02-23 07:37:00 CET [62784]: [1-1] db=,user=,app= WARNING: out of shared memory
2021-02-23 07:37:00 CET [38903]: [79-1] db=base,user=user1,app=app1 - 127.0.0.1:27930 WARNING: out of shared memory
2021-02-23 07:37:00 CET [12358]: [29-1] db=base,user=user2,app=app2 - 127.0.0.1:52043 WARNING: out of shared memory
2021-02-23 07:37:00 CET [22598]: [1-1] db=,user=,app= WARNING: out of shared memory
2021-02-23 07:37:00 CET [12446]: [57-1] db=base,user=user2,app=app2 - 127.0.0.1:39765 WARNING: out of shared memory
2021-02-23 07:37:00 CET [3804]: [10-1] db=base,user=user2,app=app2 - 127.0.0.1:3883 WARNING: out of shared memory
2021-02-23 07:37:00 CET [62823]: [118-1] db=base,user=user2,app=app2 - 127.0.0.1:27047 WARNING: out of shared memory
2021-02-23 07:37:00 CET [12446]: [58-1] db=base,user=user2,app=app2 - 127.0.0.1:39765 WARNING: out of shared memory
2021-02-23 07:37:00 CET [12358]: [30-1] db=base,user=user2,app=app2 - 127.0.0.1:52043 WARNING: out of shared memory
2021-02-23 07:37:00 CET [22600]: [1-1] db=,user=,app= WARNING: out of shared memory
2021-02-23 07:37:00 CET [22600]: [2-1] db=,user=,app= WARNING: out of shared memory
2021-02-23 07:37:00 CET [22633]: [3-1] db=,user=,app= WARNING: out of shared memory
2021-02-23 07:37:00 CET [12446]: [59-1] db=base,user=user2,app=app2 - 127.0.0.1:39765 WARNING: out of shared memory
Au niveau de la configuration:
PG 9.6.18 / debian 10.4
shared_buffers = 96G
max_worker_processes = 20
max_parallel_workers_per_gather = 6
Bonjour,
En naviguant dans les logs PG (v 9.6), je suis tombé sur ce warning:
WARNING: out of shared memory
Je sais que souvent ce message est accompagné d'une erreur et d'un "You might need to increase max_locks_per_transaction"
Mais là... non, juste le warning et rien d'autre... Du coup, je ne sais pas à quoi ce message peut bien se rapporter ni même si je dois m'inquiéter (je pense que oui quand même...). J'ai l'impression que j’atteins une limite de ressource mais je ne sais pas sur quoi agir.
Est ce que quelqu'un pourrait éclairer ma lanterne ?
Merci d'avance
Merci pour le retour,
Ce qui me parait étrange, c'est que lorsque le problème apparait, cela impacte des requêtes/transactions/traitements applicatifs bien différents. Même s'il y a une probabilité, j'ai du mal à penser que toutes ces sessions sont en "SubtransControlLock" en même temps. J'ai l’impression que le problème est global alors que de ce que je comprends des "SubtransControlLock", il devrait être local à la session (une transaction donnée ouvre trop de sous transactions).
Bonjour,
Depuis quelques jours, nous subissons des contentions sur notre BDD de production (PG 9.6), dûs à des locks de sous transactions (SubtransControlLock). De ce que j'ai compris, chaque transaction peut ourvir 64 sous transactions.
Quand le problème survient, ce n'est pas une seule requête qui "coince" mais tout un ensemble, et dès fois des requêtes qui n'ont rien à voir entre elles (qui correspondent à des périmètres de l'application bien différents), comme si ce compteur était plutôt global que local à une transaction. J'ai du mal à remonter à l'origine du problème.
Est ce qu'il y a un moyen de suivre/tracer ces sous transactions ?
Merci
En tout cas , merci à vous, je comprends mieux ce qu'il se passe et je vais pouvoir agir.
Cela vaut pour les colonnes de l'index mais aussi pour les colonnes utilisées dans des expressions.
Que je comprenne bien , les expressions dans les index ?
dverite,
Je pense, en effet, que l'on est dans la cas de figure impliquant la libc
Ancien serveur primaire:
- Debian 8.11
- libc 2.19
Nouveau serveur primaire, après bascule:
- Debian 10.4
- libc 2.28
En dehors du problème de la contrainte UNIQUE, est ce que qu'il faut reconstruire tous les index basés sur une colonne text ?
Je ne comprends absolument pas comment s'est possible.
Pour les colonnes de type texte, Il suffit d'avoir le COLLATE basé une locale qui s'appelle pareil mais qui ne trie pas pareil entre le primaire et le secondaire. C'est pourquoi le primaire et le secondaire devraient avoir exactement le même OS dans la même version.
Sur linux il y a une MAJ majeure récente de la libc qui a accru le risque ces derniers temps, cf https://blog-postgresql.verite.pro/2018 … grade.html
quand on ne réindexe pas suite à un upgrade, ou quand le couple (primaire,secondaire) a des versions décalées de la libc.
En effet, une des colonnes de la clé unique est un champ text.
Bonjour,
Suite à une bascule d'une base standby en primaire, nous nous retrouvons avec des doublons sur une table malgré une contrainte UNIQUE. La bascule s'est passé normalement.
Nous sommes sur une version pg 9.6.18. Le seul fait notable est que nous avons en même temps upgradé d'une version 9.6.15 en 9.6.18
Sur tous les doublons, nous avons une ligne avec une date d'avant la bascule et une autre d'après (nous avons des colonnes d'horodatage).
Je ne comprends absolument pas comment s'est possible.
Merci pour votre aide