Vous n'êtes pas identifié(e).
Merci pour votre réactivité !
Je viens de trouver d'ou cela vient : le chargement de shared_preload_libraries pour POWA ...
shared_preload_libraries='pg_stat_statements,powa,pg_stat_kcache,pg_qualstats'
C'est l'une des différences que j'avais entre mes 2 serveurs, et une fois désactivées, la requête passait bien ...
C'est la version 9.5.3
J'ai joué cette batterie de tests sur 3 serveurs différents, 2 ont freezé, et sur le 3eme (pourtant beaucoup moins puissant), c'est passé correctement.
Le plus simple serait que je puisse joindre des fichiers pour reproduire le problèmes, mais il n'y a à priori pas cette possibilité.
Comment puis-je vous les fournir ?
Bonjour à tous,
je rencontre un problème de freeze de postgres lors de la mise a jour d'un champ par rapport à une liste de valeurs passée en argument dans le IN de la clause WHERE.
Ce qui est étrange, c'est que le freeze n'intervient qu'a partir de 500 arguments, ce qui me ferait penser a une sorte de buffer overflow
Ex :
update accounts_v1
set active = true
where (account_id, field_id) in ( (6262,5),(6622,22),(2254,7),(2698,70),(2310,4),(6135,22),... )
A 499 entrées dans le IN, l'update passe instantanément, à 500 postgres freeze, et je suis obligé de restart le process.
Ce que j'entend par "freeze", c'est qu'il est possible de se connecter, mais que postgres ne répond plus à aucune requete (meme un "select 1" reste bloqué)
Auriez vous une idée de ce qui se passe ?
Le temsp de réponse est vraiment lié a ce serveur, tout comme le fait que le statement timeout ne fonctionne pas, car sur mon autre serveur j'ai ma réponse en 1s dans pgadmin, et ma requete est bien stoppée par timeout_statement ...
Effectivement, lorsque je lance un "select * from pg_sleep(2)" après avoir validé "set statement_timeout to 1000;", j'ai bien un statement timeout.
Par contre, si je lance un "select * from users;", ma requete n'est pas stoppée.
Comment cela se fait il ?
Pour la base, j'ai un autre utilisateur qui arrive au même résultat, 1s en psql , et 40s en pgadmin.
Pour info, j'étais en 9.3.4 ce matin, j'ai monté le serveur en 9.3.5, rien n'a changé.
Nouveaux tests effectués, je n'y comprend rien.
J'ai mis le même statement sur une autre base d'un autre serveur, il est bien pris en compte par pgadmin.
Par contre, sur mon serveur 'principal', rien n'y fait, il n'en tient pas compte.
Mes 2 serveurs sont en 9.3 , pgadmin 1.18.1
Meme le "set statement_timeout to '2000'; " n'est pas pris en compte via pgadmin (ca fonctionne bien via psql), alors que sur ma seconde base, il fonctionne parfaitement...
D'ailleurs, une même requête n'a pas le même temps de réponse via psql ou pgadmin (1s en psql, environ 40 !! via pgadmin)
Pourtant, je suis bien sur que c'est la même base, et le même compte.
Y a il des éléments de conf de pgadmin qui pourraient interférer ?
J'ai revérifié, c'est bien les mêmes infos de connexion 
Merci de la réponse rjuju
Il est toujours la, défini comme ceci :
ALTER ROLE techs SET statement_timeout = '1500000';
Après recherches, je me suis aperçu que postgres killait bien les requêtes avec la mention explicite "ERROR: canceling statement due to statement timeout", SAUF lorsque cette requête est lancée depuis un client PGADMIN !! (la même requête, lancée depuis la même machine via psql avec les mêmes identifiants de connexion est bien killée
Des idées ?
Bonjour à tous,
J'ai sur la ma base une contrainte user statement_timeout limitée à 1800000 (30mns) pour un compte donné.
Normalement, lorsque ce compte effectue une requête > à 30 mns, elle est killée par postgres.
hors, hier soir, j'ai une requete de cet user qui a duré plus de 15 heures, mettant par la même occasion le bazar sur ma base.
Avez vous une idée de pourquoi ma requête n'a pas été arrêtée par postgres cette fois ?
Merci d'avance !
J'étais déjà tombé dessus, merci.
De ce que je comprend, la personen a eu cette erreur lorsqu'elle ne fournissait pas au serveur le CA root, or dans mon cas je l'ai fait, d'ailleurs ça fonctionne très bien dès lors que je ne fournit pas de CRL.
Je n'ai pas réussi a trouver du mode débug de la transaction SSL via psql, ni réussi a afficher sur le serveur plus d'infos, du coup je ne sais pas trop comment investiguer sur ce problème.
Bon, 1ère partie du problème résolu, le durée de vie de la CRL était expirée...
Mais maintenant, j'ai l'erreur suivante : "psql: SSL error: tlsv1 alert unknown ca", toujours seulement lorsque ma CRL est activée sur le serveur
Mon pg_hba.conf
#local network
hostssl DB1 prod 172.20.0.0/16 cert clientcert=1 map=prod_srvs
(je précise que la map fonctionne bien)
Bonjour à tous,
je suis actuellement en train de mettre en place un système d'authentification par certificats pour ma DB.
J'ai créé via une pki les certificats de ma db ainsi que de mes clients.
test de connexion OK
Par contre, j'ai un problème au niveau de mes CRL.
J'ai effectué quelques tests de révocation de certificats, et maintenant, dès que j'active la directive crl dans postgresql.conf, mes connexions sont rejetées, que le certificat ait effectivement été rejeté ... ou pas.
Voici les logs du serveur :
2014-05-09 10:19:08.163 CEST [14141]: [1-1] user=[unknown],db=[unknown] LOG: connection received: host=172.20.0.102 port=46148
2014-05-09 10:19:08.173 CEST [14141]: [2-1] user=[unknown],db=[unknown] LOG: could not accept SSL connection: no certificate returned
2014-05-09 10:19:08.173 CEST [14142]: [1-1] user=[unknown],db=[unknown] LOG: connection received: host=172.20.0.102 port=46149
2014-05-09 10:19:08.174 CEST [14142]: [2-1] user=prod,db=DB1 FATAL: no pg_hba.conf entry for host "172.20.0.102", user "prod", database "DB1", SSL off
2014-05-09 10:19:08.174 CEST [14142]: [3-1] user=prod,db=DB1 DETAIL: Client IP address resolved to "172.20.0.102", forward lookup not checked.
Et du client :
psql -h 172.20.0.11 -U prod DB1
psql: SSL error: sslv3 alert certificate expired
FATAL: no pg_hba.conf entry for host "172.20.0.102", user "prod", database "DB1", SSL off.
J'ai bien vérifié les serial numbers, le certificat avec lequel je tente de me connecter n'est pas listé dans la liste des certificats révoqués
Client :
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 7 (0x7)
Server :
Revoked Certificates:
Serial Number: 01
Revocation Date: May 7 15:37:02 2014 GMT
CRL entry extensions:
X509v3 CRL Reason Code:
Key Compromise
Serial Number: 03
Revocation Date: May 6 14:13:28 2014 GMT
CRL entry extensions:
X509v3 CRL Reason Code:
Key Compromise
Serial Number: 06
Revocation Date: May 7 16:05:16 2014 GMT
CRL entry extensions:
X509v3 CRL Reason Code:
Superseded
Avez vos une idée d'ou peut venir le problème ?
Merci !
Bonjour rjuju, merci pour le retour.
Le problème vient en fait du temps que met postgres pour fixer un exclusive lock sur la table avant de pouvoir drop l'index.
Pour info si cela en intéresse certains, il a été rajouté une option concurrently sur le drop à partir de la 9.2
bonjour,
j'ai mis en place cette solution depuis quelques jours et elle fonctionne bien, et ce jour, j'ai eu un soucis lors du drop d'un index (non utilisé du coup, comme un nouvel index avait été créé) : la requete a mis beaucoup de temps a s’exécuter, et a mis en Wait toutes les requêtes suivantes.
Pourriez vous m'expliquer pourquoi cela se produit ?
Merci d'avance !
Oui, il s'agit du même index, le but étant de ne pas voir mes indexs grandir indéfiniment en terme d'espace disque notamment.
Je n'avais pas réussi à trouver cette information dans la doc...
Je ne fais pas tout dans une transaction, juste le drop de l'ancien index et le rename du nouveau (toto_idx_new) pour lui donner le nom de l'ancien (toto_idx), dans le but d'éviter le cas de figure ou le drop se passe bien, et le rename non. (et donc dans ce cas, et si je vous suit bien, mon index sera tout de même fonctionnel, il n'aurait juste pas le bon nom ?)
Bonjour à tous,
Je cherche à remplacer certains indexs de ma base trop bloatés par des indexs recréés via un "create index concurrently" , suivi d'un "drop index idx ; alter index idx_new rename to idx" englobé dans une transaction.
Je me pose une question sur comment la base fonctionne pendant le laps de temps ou les 2 indexs coexistent, le temps que le drop / rename ait eu lieu.
Comment la base sait quel index elle doit interroger ?
Est ce que cela peut poser des problèmes ?
Merci
Merci de votre réponse guillaume
La transaction s'est arrêtée car j'ai renseigné le paramètre statement_timeout=1800000 sur la base (30 mns), et que la transaction a duré ce temps la.
Il n'y a a priori pas de fichiers temporaires sur la base, c'est bein le dossier dans 'base' qui fait cette taille la (j'ai créé un tablespace temporaire sur un autre volume, il est vide)
De plus, ils auraient du se supprimer après restart de la base dans ce cas, non ?
J’avais peut etre pensé à une table temporaire, amis lorsque je trie les tables par tailles, je ne voit rien qui correspond à ça...
Bonjour à tous,
Il y a peu, nous avons tenté sur notre base une requête d'ajout de colonne dans une table de 20 Go avec un default false. (base en production)
La requête a mis énormément de temps a se faire, ne s'est pas terminée, et à surtout fait grimper la taille totale de la base de 170 à 200Go environ.
Suite au plantage, nous avons refait le même requête, sans le default false, et la cela a fonctionné nickel, en quelques secondes la requête s'était terminée, la base n'a pas bougé niveau taille.
Bref.
Ce qui est étrange, c'est que lorsque je regarde la taille des tables une à une, je ne vois aucune table qui a grossi, et je ne comprend pas ou sont passés ces 30 Go !
Pour tenter de regagner cet espace , j'ai effectué un vacuum full, mais malgré cela, je ne retrouve toujours pas mes 30 GO
Différences vues :
psql db
\l+
db | toto | UTF8 | en_GB.UTF-8 | en_GB.UTF-8 | | 131 GB | pg_default |
Et la requête que je lance pour voir le détail de ma base :
select sum(pg_table_size(table_schema || '.' || table_name)) as data,
sum(pg_indexes_size(table_schema || '.' || table_name)) as index,
sum(pg_total_relation_size(table_schema || '.' || table_name)) As total
FROM information_schema.tables;
Résultat : 99 Go
65117700096 | 33858953216 | 98976653312
Quand je fais le cumul des tailles de toutes les tables (data + index + toast), je tombe aussi sur 99 Go.
Sauriez vous pourquoi j'ai ce soucis ?
ps : Je suis en version 9.0
Je ne l'avais pas fait, effectivement
Cela marche beaucoup mieux, pgbenchs a l'appui.
Merci beaucoup rjuju
salut a tous,
j'utilise pgpool en tant que pooler de connexion (aucun soucis) , et j'essaie en ce moment de le passer en mode load balancer pour les requetes select.
J'ai donc activé l'option load_balance_mode = true,
et changé le
backend_hostname0 = 'localhost'
backend_port0 = 5432
backend_weight0 = 1
en
backend_hostname0 = '192.168.1.230'
backend_port0 = 5432
backend_weight0 = 0.5
backend_hostname1 = '192.168.1.231'
backend_port1 = 5432
backend_weight1 = 0.5
pour y ajouter mes 2 hotes (localhost est le .230)
Le .230 étant le maitre, le .231 l'esclave.
Mon soucis, c'est que pgpool ne semble pas vouloir prendre les 2 hotes en compte.
Mes autorisations sur les serveurs postgres sont OK dans pg_hba.conf ; d'ailleurs si je met seulement l'un des 2 hotes en hostname0, ça fonctionne, les requetes lui sont bien envoyées. (avec pgbench ou via un select manuel par exemple)
Des que je met les 2, ca ne prend en compte que le premier que je déclare.
Pourtant, lorsque le lance pgpool avec l'option de debug, il semble me prendre les 2 nodes
------
2012-12-18 12:12:42 DEBUG: pid 10173: key: backend_hostname0
2012-12-18 12:12:42 DEBUG: pid 10173: value: '192.168.1.230' kind: 4
2012-12-18 12:12:42 DEBUG: pid 10173: key: backend_port0
2012-12-18 12:12:42 DEBUG: pid 10173: value: 5432 kind: 2
2012-12-18 12:12:42 DEBUG: pid 10173: pool_config: port slot number 0
2012-12-18 12:12:42 DEBUG: pid 10173: key: backend_weight0
2012-12-18 12:12:42 DEBUG: pid 10173: value: 0.5 kind: 3
2012-12-18 12:12:42 DEBUG: pid 10173: pool_config: weight slot number 0 weight: 0.500000
2012-12-18 12:12:42 DEBUG: pid 10173: key: backend_hostname1
2012-12-18 12:12:42 DEBUG: pid 10173: value: '192.168.1.231' kind: 4
2012-12-18 12:12:42 DEBUG: pid 10173: key: backend_port1
2012-12-18 12:12:42 DEBUG: pid 10173: value: 5432 kind: 2
2012-12-18 12:12:42 DEBUG: pid 10173: pool_config: port slot number 1
2012-12-18 12:12:42 DEBUG: pid 10173: key: backend_weight1
2012-12-18 12:12:42 DEBUG: pid 10173: value: 0.5 kind: 3
2012-12-18 12:12:42 DEBUG: pid 10173: pool_config: weight slot number 1 weight: 0.500000
2012-12-18 12:12:42 DEBUG: pid 10173: key: enable_pool_hba
2012-12-18 12:12:42 DEBUG: pid 10173: value: true kind: 1
2012-12-18 12:12:42 DEBUG: pid 10173: num_backends: 2 num_backends: 2 total_weight: 1.000000
2012-12-18 12:12:42 DEBUG: pid 10173: backend 0 weight: 1073741823.500000
2012-12-18 12:12:42 DEBUG: pid 10173: backend 1 weight: 1073741823.500000
----
Est ce que je rate quelque chose ?
Merci d'avance !
Bonjour a tous,
petite question du jour,
j'ai dans ma supervision (munin) un graphe des transactions, et j'ai remarqué par rapport à ça que j'avaus des rolled back transactions sur ma base (pics environ toutes les 2h)
Y a il un moyen de savoir quelles sont ces transactions, et pourquoi elles 'ont pu être commitées ?
Merci de votre aide !
Dans le meme genre, j'ai ma base qui s'est complètement bloquée à cause du nombre trop important de connexions, et je n'ai eu d'autres choix que de l'arreter et la redémarrer.
Dans ma supervision munin, je joius qu'il y a eu un nombre très importans de connexions en "waiting for lock"
Je penche donc pour une requete qui aurait bloqué tout le reste ... y a il un moyen de savoir laquelle ? (car si j'ai bien compris pg stat activity / pg locks ne gèrent que les requetes en cours non ?)
Merci !
Parfait, je vous remercie !
bonjour a tous,
j'ai sur la base que j'administre des verrous RowExclusiveLocks depuis quelques jours, et ce beaucoup plus qu'a l'accoutumée, (vues dans mes graphes puis dans pg_locks).
J'aimerais savoir quelles sont les requetes qui en sont la cause, pourriez vous me dire comment les trouver ?
Merci d'avance
