Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
#76 Général » Timing de requetes sur PSQL » 05/09/2017 17:33:18
- duple
- Réponses : 3
Bonjour,
En utilisant postgresql sur linux, connaissez vous un moyen de monitoriser la durée d'execution des requêtes effectuée sur ligne de commande psql ?
Pour être clair, j'aimerai conserver dans un fichiers les durées d’exécutions de plusieurs commandes psql.
#77 Re : Réplication » FATAL: remaining connection slots are reserved for non-replication su » 05/09/2017 10:37:03
Il y aurait pas t il d'autres options possible ?
J'ai bien arrêté le service postgres de la réplique la veille dans la soirée, sans changer de configuration sauf le paramètre archive_command du master. Le lendemain matin je regarde les logs (heure midi) et je constate ces erreurs.
#78 Re : Réplication » FATAL: remaining connection slots are reserved for non-replication su » 05/09/2017 09:20:06
Bonjour,
Merci de votre réponse.
Oui, il existe bien un serveur secondaire, mais ce qui est bizarre c'est que je l'avait arrêté durant ce temps en raison d'un manque d'espace disque. Donc je ne vois pas comment le serveur secondaire tenterait encore de s'y connecter au primaire.
#79 Réplication » FATAL: remaining connection slots are reserved for non-replication su » 01/09/2017 16:36:55
- duple
- Réponses : 4
Bonjour,
Je dispose d'un serveur postgresql sous linux.
En regardant les logs d'aujourd'hui, je trouve des messages tels que:
> FATAL: remaining connection slots are reserved for non-replication superuser connections
> ERROR: requested WAL segment 00000001000005240000009B has already been removed
Pouvez vous svp m'expliquer davantage sur les raisons d'apparitions de ces erreurs ?
#80 Re : Général » transaction entre plusieurs commandes pg_dump ? » 04/08/2017 12:15:12
Salut,
Si t'as la version 9.4 et supérieur je crois, tu peux utiliser l'option jobs "-j" du commande pg_dump pour augmenter la vitesse de ton dump avec un format de sortie repertoire.
Jobs:
Exécute une sauvegarde parallélisée en sauvegardant njobs tables simultanément. Cette option réduit la durée de la sauvegarde mais elle augmente aussi la charge sur le serveur de base de données. Vous ne pouvez utiliser cette option qu'avec le format de sortie répertoire car c'est le seul format où plusieurs processus peuvent écrire leur données en même temps.
Pour plus d'info: https://docs.postgresql.fr/9.6/app-pgdump.html
#81 Re : Général » Violates check constraint » 03/08/2017 10:50:49
Ok, le problème est règlé avec :
ADD CONSTRAINT ckc_type_error_inject_type_err CHECK (type_error_inject_wr IS NULL OR length(type_error_inject_wr) <= 150);
#82 Général » Violates check constraint » 03/08/2017 10:44:18
- duple
- Réponses : 1
Bonjour,
J'ai créé une table telle que:
CREATE TABLE suivi_inject_tl.type_error_inject_wr
(
id_type_error_inject_wr integer NOT NULL DEFAULT nextval('suivi_inject_tl.type_error_inject_wr_id_type_error_inject_wr_seq'::regclass),
type_error_inject_wr character varying(150),
CONSTRAINT pk_type_error_inject_wr PRIMARY KEY (id_type_error_inject_wr),
CONSTRAINT ckc_type_error_inject_type_err CHECK (type_error_inject_wr IS NULL OR type_error_inject_wr::text <= '150'::text)
)
Le souci est que quand je fais un INSERT INTO suivi_inject_tl.type_error_inject_wr(type_error_inject_wr) values ('Truc que je veux insérer');
>>> Cela me renvoie à l'erreur : ERROR: new row for relation "type_error_inject_wr" violates check constraint "ckc_type_error_inject_type_err"
Je ne comprends pas pourquoi cette erreur apparait avec CONSTRAINT ckc_type_error_inject_type_err CHECK (type_error_inject_wr IS NULL OR type_error_inject_wr::text <= '150'::text);
Avez vous idée du pourquoi et pouvez vous expliquer ?
Merci
#83 Re : Réplication » REPLICATION : WAL dans pg_xlog non supprimé » 25/07/2017 12:53:18
Je met un bilan de résultat pour ceux qui sont intéressés:
gleu> normalement si je comprends bien, si archive_mode=on et la commande archive_command est renseignée avec une copie , les wal seront transmis vers l'emplacement définis dans archive_command. Par conséquent, si l'on ne met rien dans archive_command les wal ainsi seront entassés dans pg_xlog et seront toujours en attente de copie (wal.ready). Avec un test, j'ai utilisé archivecleanup commande depuis la réplique vu que la réplique connait quel est le wal déjà joué donc déjà mise en .done qu'on peut supprimer. Je rappelle que l'objectif ici est de seulement supprimer les wal déjà joués pour réduire et éviter le gonflement d'espace occupé par les wal en attentes de copie. Une fois les wal déjà joué supprimés, on désactive archive_mode. Et ainsi postgresql reprend son jeu normal sans mode d'archivage. Cette opération à été testé sur une base de test avec un résultat positif
Peut être avez vous des objections à ceux ci ?
rjuju> Mettre archive_command à false, je viens de tester, çà ne résolu pas le problème, d'ailleurs je ne comprends pas pourquoi.
Par contre, je pense que l'idée est assez la même ou presque, une autre astuce (plus bas) vérifiée et mise en application résolu bien le problème.
Puisque dans le cas où l'on ne dispose pas de serveur de réplique et/ou que l'on aime pas trop utiliser la commande archivecleanup, pour supprimer les wal supprimables on peut utiliser la méthode suivante. Tout simplement, on ne désactive pas archive_mode mais cependant on met archive_command = '/bin/true'. Cela conduira en quelque sorte à une illusion de copie, qui va entrainer ainsi de mettre les wal.ready en wal.done sur le master qui effacera les wal pouvant être supprimé. Postgresql gardera ensuite dans pg_xlog les wal nécessaires à son mode de vie normal selon vos paramétrages.
En tout cas, merci beaucoup aux aides et conseils que vous avez apporter pour ce sujet.
#84 Re : Réplication » REPLICATION : WAL dans pg_xlog non supprimé » 18/07/2017 14:32:06
Je ne comprends pas, comment çà manuel?
L'option %r de pg_acrchivecleanup est manuel vous dites ?
#85 Re : PgAdmin3 » Réasultat de requête trop long (...) » 18/07/2017 08:49:11
Bonjour à tous, je soulève le sujet car dans mon pgAdmin j'ai pas Nombre maximum de caractères par colonne, dans Fichier > Préférences > Editeur de requêtes
#86 Re : Réplication » REPLICATION : WAL dans pg_xlog non supprimé » 18/07/2017 08:24:49
Bonjour,
J'ai l'impression que vous essayez de vous en sortir sans faire d'archivage. C'est une très mauvaise idée et ça va vous péter à la figure. Configurez l'archivage, et ça ira beaucoup mieux
>>> Vous voulez sans doute parler si la réplication s'arrête durant un certain laps de temps et qu'il faudra la reconstruire pour la redémarrer n'ayant plus les jeux de wal nécessaires pour rattraper le master non ? Ou quels autres inconvénients signalez vous ?
Il ne faut surtout pas utiliser pg_archivecleanup sur le répertoire pg_xlog du serveur primaire
Pourquoi ? On a fait un jeu de test sur pg_archivecleanup hier soir et çà à marcher pourtant !!! Mais j'aimerai quand même savoir la raison pour que vous déconseillez cette méthode.
Auparavant, on avait déjà désactive archive_mode durant un certain laps de temps mais les wal dans pg_xlog ne diminuaient pas, et engager toujours l'espace disque. Puis on a monté le répertoire dans la réplique, qu'on a ensuite purgé les pgxlog avec pg_arhivecleanup command, et çà marchait.
#87 Re : Réplication » REPLICATION : WAL dans pg_xlog non supprimé » 17/07/2017 17:40:02
MASTER SETUP
Step1: paramétrage postgresql.conf
wal_level = replica
max_wal_senders = 8
max_wal_size = 1GB
hot_standby = on
Step2: Creation de l'utilisateur pour la replication
Step3: Parametrage de pg_dba.conf
SLAVE SETUP
Step4: Arrêt de l'instance
Step5: Restauration du master pour créer la replique avec >>> pg_basebackup
Step6: Copie/coller du postgresql.conf du master vers le slave
Step7: Creation du recovery.conf
standby_mode = on
primary_conninfo = 'host=masterhost user=userrepl'
Step8: Démarrage du slave
>>>> Je précise ici qu'on a mis archive_command = '' sur le maitre
Je pense que le problème vient d'ici, on a désactivé l'archive_command sans pour autant mis archive_mode = 'off' donc archive_mode toujours activé les fichiers dans pg_xlog/archive_status sont tous mit en .ready et en attente de copie par archive_command, du coup les wal dans pg_xlog s'accumulent et prennent de l'espace.
Pour solutionner nous pensons à mettre archive_mode = 'off' puis redémarrer le master. Monter pg_xlog dans le serveur de replique et inserrer pg_archivecleanup dans recovery.conf pour supprimer les wal qui ne sont plus utiles dans le repertoire pg_xlog monté.
Qu'en pensez vous ? Nous allons faire un jeu de test.
#88 Re : Réplication » REPLICATION : WAL dans pg_xlog non supprimé » 17/07/2017 10:30:42
select * from pg_stat_archiver >>
archived_count last_archived_wal last_archived_time failed_count last_failed_wal last_failed_time stats_reset
0 0 2017-07-15 12:41:24.872644+00
#89 Re : Réplication » REPLICATION : WAL dans pg_xlog non supprimé » 17/07/2017 10:29:21
Merci pour cette réponse.
C'est-à-dire ? Parce que dit comme ça ça ressemble à une très très mauvaise idée. Les WALs doivent être archivés avant d'être rejoué.
>>>C'est à dire que le système actuel n'utilise pas d'archive command dans postgresql.conf.
Pour les autres information:
select * from pg_stat_archiver >>
archived_count last_archived_wal last_archived_time failed_count last_failed_wal last_failed_time stats_reset
0 0 2017-07-15 12:41:24.872644+00
select * from pg_replication_slots >> Aucun resultat
wal_keep_segments = 100
Effectivement, je crois que vous aviez raison. Faudrait peut être diminuer wal_keep_segments ? Justement puisque le système n'utilise pas archive_command on a préféré définir wal_keep_segments à 100.
Pouvez vous conseiller sur la bonne solution à prendre ?
#90 Réplication » REPLICATION : WAL dans pg_xlog non supprimé » 17/07/2017 09:04:40
- duple
- Réponses : 14
Bonjour,
Nous travaillons avec un postgresql-9.6 sur un environnement linux.
J'ai monté une base replique sur un autre serveur en mode streaming en utilisant les paramètres de postgres de façon à ce que le slave joue les WAL directement depuis l'emplacement pg_xlog de serveur maitre. C'est bon, la réplication marche, mais, le problème étant que les fichiers dans pg_xlog du serveur maitre ne sont pas effacés et s'accumulent, ce qui bouffent beaucoup d'espace disque. Le contenu du fichier recovery.conf est comme ceci:
standby_mode = 'on'
primary_conninfo = 'host=host_maitre port=port_maitre user=rep password=reppassword'
trigger_file = '/tmp/postgresql.port.trigger.5434'
Est ce normal que ces fichiers wal dans pg_xlog ne sont pas supprimés, comment fait on pour y remédier car on commence à manquer d'espace disque.
J'ai pensé à utiliser pg_archivecleanup et insérer cette commande dans le recovery.conf. Mais je ne crois pas que pg_archivecleanup dispose d'option pour se connecter au serveur maitre depuis le slave ?
Pouvez vous nous aider sur ces points ?
Merci d'avance.
#91 Re : Général » Embouteillage soudaine entre les requêtes qui se figent » 23/06/2017 11:30:15
- Disque ext4 partitionné en GPT
- RAM 128Go
Config postgres:
"application_name"-----"pgAdmin III - ??diteur de requ??tes"
"archive_command"-----"rsync -a %p postgres@fsd3.numen.mg:/part_2/db_replica/wal_archives/serv1-9.4.5/%f"
"archive_mode"-----"on"
"bytea_output"-----"escape"
"checkpoint_segments"-----"32"
"client_encoding"-----"UNICODE"
"client_min_messages"-----"notice"
"data_checksums"-----"off"
"DateStyle"-----"ISO, MDY"
"default_text_search_config"-----"pg_catalog.french"
"dynamic_shared_memory_type"-----"posix"
"effective_cache_size"-----"39GB"
"hot_standby"-----"on"
"huge_pages"-----"try"
"lc_collate"-----"fr_FR.UTF8"
"lc_ctype"-----"fr_FR.UTF8"
"lc_messages"-----"en_US"
"lc_monetary"-----"en_US"
"lc_numeric"-----"en_US"
"lc_time"-----"en_US"
"listen_addresses"-----"*"
"log_autovacuum_min_duration"-----"0"
"log_checkpoints"-----"on"
"log_connections"-----"on"
"log_destination"-----"stderr"
"log_directory"-----"/data01/PostgreSQL/9.4.5/pg_log/log_srvl1_5452"
"log_disconnections"-----"on"
"log_filename"-----"postgresql-%Y-%m-%d.log"
"log_line_prefix"-----"%t [P:%p][D:%d]: [%l-1] "
"log_lock_waits"-----"on"
"log_min_duration_statement"-----"500ms"
"log_rotation_age"-----"1d"
"log_rotation_size"-----"10MB"
"log_statement"-----"none"
"log_temp_files"-----"0"
"log_truncate_on_rotation"-----"off"
"logging_collector"-----"on"
"maintenance_work_mem"-----"7680MB"
"max_connections"-----"400"
"max_stack_depth"-----"2MB"
"max_wal_senders"-----"5"
"port"-----"5452"
"random_page_cost"-----"2"
"server_encoding"-----"UTF8"
"server_version"-----"9.4.5"
"shared_buffers"-----"15GB"
"TimeZone"-----"localtime"
"transaction_deferrable"-----"off"
"transaction_isolation"-----"read committed"
"transaction_read_only"-----"off"
"wal_buffers"-----"16MB"
"wal_keep_segments"-----"100"
"wal_level"-----"hot_standby"
"work_mem"-----"480MB"
#92 Re : Général » Embouteillage soudaine entre les requêtes qui se figent » 23/06/2017 08:07:46
Salut,
Gleu> Oui les CPU sont largement utilisés quand il existe beaucoup de requêtes en lancement (en phase de production). Donc tu veux dire que le serveur (le CPU) est en surcharge ? Qu'il faudrait peut être migré quelque bases dans un autre serveur, ou quel action d'amélioration peux tu me conseiller ?
****
En fait entre parenthèse j'aimerai savoir si possible, analyze recolte les statistiques pour être utilisé par la suite par l'optimisateur de requête, aussi, est ce que "explain analyze" récolte aussi les statistiques ou lance t elle tout simplement la requête en affichant son parcours et ses coûts. En gros, est ce que explain analyze hérite elle aussi des mécanismes de la commande ANALYZE ?
#93 Re : Général » Embouteillage soudaine entre les requêtes qui se figent » 21/06/2017 19:35:29
Je n'ai pas encore eu l'occasion d'utiliser vmstat au moment du lenteur aujourd'hui. Sinon, si çà peut aider, le résultat d'un htop seront un peu pareil à comme ceci:
1 [||||||||||||||||||||||||||||||||||||||97.5%] 7 [||||||||||||||||||||||||||||||||||||||91.8%] 13 [||||||||||||||||||||||||||||||||||||||95.6%] 19 [||||||||||||||||||||||||||||||||||||||95.0%]
2 [||||||||||||||||||||||||||||||||||||||96.9%] 8 [||||||||||||||||||||||||||||||||||||||93.2%] 14 [||||||||||||||||||||||||||||||||||||||96.9%] 20 [||||||||||||||||||||||||||||||||||||||94.4%]
3 [||||||||||||||||||||||||||||||||||||||99.4%] 9 [||||||||||||||||||||||||||||||||||||||91.3%] 15 [||||||||||||||||||||||||||||||||||||||96.9%] 21 [||||||||||||||||||||||||||||||||||||||95.7%]
4 [||||||||||||||||||||||||||||||||||||||96.2%] 10 [||||||||||||||||||||||||||||||||||||||95.7%] 16 [||||||||||||||||||||||||||||||||||||||90.7%] 22 [||||||||||||||||||||||||||||||||||||||94.4%]
5 [||||||||||||||||||||||||||||||||||||||95.6%] 11 [||||||||||||||||||||||||||||||||||||||85.6%] 17 [||||||||||||||||||||||||||||||||||||||96.2%] 23 [||||||||||||||||||||||||||||||||||||||92.5%]
6 [||||||||||||||||||||||||||||||||||||||95.0%] 12 [||||||||||||||||||||||||||||||||||||||95.0%] 18 [||||||||||||||||||||||||||||||||||||||88.3%] 24 [||||||||||||||||||||||||||||||||||||||86.2%]
Mem[||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||30673/129190MB] Tasks: 755, 231 kthr; 32 running
Swp[|||||| 3416/61033MB] Load average: 52.17 55.64 46.91
Uptime: 74 days, 02:00:17
***********************
Par ailleurs, j'ai lancé un EXPLAIN(buffers,analyze) de la requête qui subissait une lenteur et effectivement j'ai vu que postgresql utilisée une partie de bloc de disque pour avoir les résultats. Comme ex: Buffers: shared hit=167859 read=14243 et bien sur , plus il utilisise de disque plus la durée d'execution de la requête est longue. Puis, une fois la requête executée elle revient à son temps d'execution normale avec une lecture seulement dans le cache cette fois ci, avec Buffers: shared hit=214390. Mais la vrai question est pourquoi la requête tout d'un coup à besoin de lire dans les blocs pour s'executer, ou est ce que c'est lié au concurrence entre les instances, que j'ai mentionné plus haut ?
#94 Re : Général » Embouteillage soudaine entre les requêtes qui se figent » 20/06/2017 17:30:13
Bonjour, je relève le sujet car je pense que les attentes sur les verrous sont des conséquences mais pas de causes.. Puisque ces attentes n'apparaissent qu'à 3/4 fois par jour (ennuyant bien sur), mais ces attentes sont dus je pense à une variation soudaine de la durée d’exécution des requêtes:
- Soit à cause du chemin du planner qui à changer ?
- Soit à cause du charge du serveur énorme.
Mais pourquoi ???
Car en effet, la base est installée dans une instance. Or sur le serveur physique (128Go de RAM) il y existe 3 instances qui elles aussi conservent des dizaines/ vingtaines de base de données (certaines de grande tailles > 200Go, et d'autres petites). Ce qui me laisse à penser que peut être le serveur n'arrive pas à suivre les demandes. Que les instances se bouffent les ressources entre elles peut être? Ce qui va entrainer une réservation de cache par d'autres instances, qui pénaliseront les autres instances surtout les grandes bases, et qui va ensuite entrainer la lenteur de la requête , non ???
Est ce que vous pensez que cette théorie est plausible ? Une remarque toute fois, c'est surtout les grandes bases qui subissent ces lenteurs soudaines de requêtes et après genre 5minutes, les requêtes reprennent son rythme d'execution normale !!!
Pour les logs, rien d'incroyable, mis à part les logs style attentes/acquisition de verrous suite à un laps de temps.. ce qui je pense n'étant pas la cause mais la conséquence ici , non ???
Svp, merci de porter votre attention sur ce sujet , car je ne trouve pas d'autres explications alors que le problème est assez énervant et devrait être résolu, alors comptant sur vos soutiens et idées pour aider 
#95 Re : Général » Embouteillage soudaine entre les requêtes qui se figent » 08/06/2017 11:04:04
Après avoir revérifier les logs, il s'agit surement de problème de verrou.
Mais ce qui m'étonne toujours c'est que pourquoi existe il cette attente de verrou, pourquoi la durée d'execution de la requête détentive du verrou vire t elle de 1 sec à 10 minutes ?
#96 Re : Général » Embouteillage soudaine entre les requêtes qui se figent » 08/06/2017 09:05:04
Bien vu, et merci pour cette réponse, là je suis d'accord. Ce qui m'étonne toute fois, c'est que les durées d'attentes sont de 10 minutes ou plus, alors que la requête utilisant SELECT FOR UPDATE elle met 1 à 2sec en moyenne à s’exécuter. Par ailleurs, j'ai eu la chance d'avoir pu visualiser le phénomène hier sur l'état du serveur dans pgAdmin. La requête s’exécute et ne se termine pas au moment prévu, son temps d’exécution augmente, puis viens une autre requête avec la même situation, et puis une autre et ainsi de suite.. Pourtant, après vérification il n'existe pas de blocage entre ces requêtes donc je suppose qu'ici il n'y a pas d'attente de verrou non ? Et pourtant c'est requêtes s'accumulant qui normalement met 1 ou 2 sec à s’exécuter ne se terminent qu'après 10 min ou plus, elles se terminent tous à peu près en même temps après mais toute fois avec 1 sec d’écart à peu près.
Est ce toujours un problème de verrou ou d'où pourrait provenir le problème? Est ce que par hasard il y aurait il une liaison avec les ecritures checkpoint, un paramétrage peut être mal configuré, on a checkpoint_segments = 64 avec checkpoint_completion_target = 0.8 ?
Bien à vous
#97 Re : Général » Embouteillage soudaine entre les requêtes qui se figent » 07/06/2017 14:03:47
Qu'entendez vous par métriques systèmes et postgres ?
En ce qui concerne les log postgres, il y a pas trop de piste, seulement des messages du genre :
LOG: process 52694 still waiting for ShareLock on transaction 53543073 after 8000.051 ms
DETAIL: Process holding the lock: 52320. Wait queue: 52694.
CONTEXT: while locking tuple (558553,3) in relation "object_item"
Ce qui est assez normale vu que, les requêtes sont en fil d'attentes.
Et sinon les logs figurent aussi des messages du genre:
LOG: process 52839 acquired AccessExclusiveLock on tuple (558590,3) of relation 7539547 of database 16384 after 642909.003 ms
CONTEXT: SQL statement "SELECT id FROM numenvault.Object_item WHERE id = $1 FOR UPDATE"
>>> Ici, les requêtes retournent à leur temps d'execution normale
Sinon, à part çà les logs ne montrent pas grand chose, seulement les durées d’exécution de requêtes et les logs de connections et de déconnections.
>>>>> Ce qui m'étonne c'est que qu'est ce qui fait que la durée d’exécution des requêtes augmentent elles tout d'un coup, passage d'1seconde en 10 minutes soudainement et revient à la normale après? C'est comme si le planner a changé de chemin ou je ne sais pas ?
Est ce que ceci y ait déjà survenu chez vous, avez vous une avis sur le sujet ?
Je tiens toutefois à signaler que la taille des bases de données dont je parle ici atteigne les 400Go ou plus.
#98 Général » Embouteillage soudaine entre les requêtes qui se figent » 07/06/2017 09:41:11
- duple
- Réponses : 12
Bonjour à tous,
Nous utilisons postgresql 9.4 sur un environnement linux, et nous constatons qu'il arrive dés fois, environ 1,2,5 fois par jour un embouteillage soudaine des requêtes sur le serveur. Cela se produit durant 10 minutes ou 15 minutes, les requêtes deviennent aussitôt lentes (si par exemple la requête s’exécute en 1 seconde normalement elle se fige et ne se termine pas durant ce temps) tout à coup et ne se termine pas durant cette durée, aussi les requêtes commencent alors à s'accumuler durant cette période et la charge du serveur qui pourrait commencer à s'augmenter également au niveau des CPU. Puis après attente, on constate que l'embouteillage est fini, et les requêtes se finissent soudainement et reprend son durée d’exécution normales.
Je tiens à remarquer qu'il n'y a pas blocage entre les requêtes, ou sinon seulement 4 ou 7 requêtes bloquantes sur 65 requêtes qui s'accumulent. Le blocage ne s'apparait qu'après, ie que vu que les requêtes s'accumulent entre elles, viennent alors ensuite quelques blocages mais qui je pense ne sont pas la cause mais l'effet de cet embouteillage soudain vraiment gênant. J'utilise le mot embouteillage vu que je ne trouve pas d'autres termes jusqu'à présent pour expliquer le problème, peut être un freeze? Durant la lenteur, même si j'annule les autovaccum, l'embouteillage ne se termine pas toujours.
Pour plus d'information nous utilisons également tomcat pour servir de serveur web applicatif, seulement là aussi je ne pense pas que le problème pourrait y venir.
Sauriez vous la cause de ce problème, car la situation devient assez gênante. Avez vous des solutions à proposer ?
Merci de votre attention à ce sujet
#99 Re : Général » GESTION VERROU Postgresql » 02/06/2017 12:20:13
Je vous en remercie bcp pour vos réponses
#100 Général » GESTION VERROU Postgresql » 01/06/2017 18:08:22
- duple
- Réponses : 2
Bonjour,
J'ai trouvé des messages du genre ci-dessous dans le log postgres :
LOG: process 31740 still waiting for AccessExclusiveLock on object 0 of class 1262 of database 0 after 1000.062 ms
DETAIL: Process holding the lock: 8655. Wait queue: 31688, 31740, 31359
Mais je ne les comprends pas vraiment est ce que vous pouvez me les expliquer svp, çà serait super de votre part
Par ailleurs, pour confirmation, les log genre LOG: disconnection: session time: 0:01:00.373 voudraient elles dire qu'une session a été déconnectées , mais est ce du fait de la deconnexion de l'utiliateur , ou le processus a été contraint d'être déconnecté ??
Bonne soirée à vous, et merci d'avance de l'attention que vous pouvez apporter à ce sujet ^_^