PostgreSQL La base de donnees la plus sophistiquee au monde.

Forums PostgreSQL.fr

Le forum officiel de la communauté francophone de PostgreSQL

Vous n'êtes pas identifié(e).

#1 Re : Général » Erreur pg_upgrade sur la révocation de droit » 04/10/2022 16:26:00

rjuju a écrit :

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


rjuju a écrit :

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


rjuju a écrit :

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

#2 Re : Général » Erreur pg_upgrade sur la révocation de droit » 04/10/2022 15:13:04

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

#3 Re : Général » Erreur pg_upgrade sur la révocation de droit » 04/10/2022 09:40:06

 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.

#4 Général » Erreur pg_upgrade sur la révocation de droit » 04/10/2022 09:28:26

pitpoule
Réponses : 6

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.

#5 Re : Général » Message "WARNING: out of shared memory" » 15/03/2021 09:41:48

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

#6 Re : Général » Message "WARNING: out of shared memory" » 26/02/2021 09:41:33

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.

#7 Re : Général » Message "WARNING: out of shared memory" » 25/02/2021 11:17:20

Merci pour vos conseils, je vais regarder ça pour une mise en place smile

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:212

#8 Re : Général » Message "WARNING: out of shared memory" » 25/02/2021 11:00:35

rjuju a écrit :

J'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 smile
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.

#9 Re : Général » Message "WARNING: out of shared memory" » 25/02/2021 10:16:04

postgres$ for p in $(pgrep postgres); do grep "VmPTE:" /proc/$p/status; done | awk '{pte += $2} END {print pte / 1024}'
35009.7

35G, je ne saurais dire, si c'est peu ou beaucoup

#10 Re : Général » Message "WARNING: out of shared memory" » 25/02/2021 09:01:00

rjuju a écrit :

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 ?

#11 Re : Général » Message "WARNING: out of shared memory" » 24/02/2021 18:36:53

Merci pour le retour smile

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

#12 Re : Général » Message "WARNING: out of shared memory" » 24/02/2021 09:19:46

ruizsebastien a écrit :

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

#13 Re : Général » Message "WARNING: out of shared memory" » 24/02/2021 09:18:32

rjuju a écrit :

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)

#14 Re : Général » Message "WARNING: out of shared memory" » 24/02/2021 09:13:54

dverite a écrit :

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 warnings

max_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 ?

#15 Re : Général » Message "WARNING: out of shared memory" » 23/02/2021 18:56:25

      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 functions

Pour la verbosité des logs, je modifierai demain... on génère tellement de logs que j'ai peur que ça coince niveau disque

#16 Re : Général » Message "WARNING: out of shared memory" » 23/02/2021 17:06:27

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

#17 Re : Général » Message "WARNING: out of shared memory" » 23/02/2021 16:49:53

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

#18 Général » Message "WARNING: out of shared memory" » 23/02/2021 13:20:03

pitpoule
Réponses : 26

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

#19 Re : Général » Locks "sous transactions" » 25/08/2020 13:04:42

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).

#20 Général » Locks "sous transactions" » 19/08/2020 11:30:46

pitpoule
Réponses : 2

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

#21 Re : Général » Contrainte UNIQUE mais doublon dans des tables » 02/06/2020 15:47:15

En tout cas , merci à vous, je comprends mieux ce qu'il se passe et je vais pouvoir agir.

#22 Re : Général » Contrainte UNIQUE mais doublon dans des tables » 01/06/2020 22:53:14

rjuju a écrit :

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 ?

#23 Re : Général » Contrainte UNIQUE mais doublon dans des tables » 01/06/2020 16:04:14

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 ?

#24 Re : Général » Contrainte UNIQUE mais doublon dans des tables » 01/06/2020 12:12:28

dverite a écrit :

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.

#25 Général » Contrainte UNIQUE mais doublon dans des tables » 29/05/2020 17:23:52

pitpoule
Réponses : 8

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

Pied de page des forums

Propulsé par FluxBB