Vous n'êtes pas identifié(e).
Bonjour
Je rencontre actuellement un problème avec PostgreSQL sur un poste Windows 7 32 bits
La version installée de PostgreSQL est la 9.5
Le message retourné (à la connexion) par le logiciel client est :
"n'a pas pu lancer le nouveau processus fils pour la connexion : No error"
Dans le log de PostgreSQL j'ai ces deux lignes qui sont ajoutées de nombreuses fois :
2016-11-05 07:59:42 CET LOG: could not reserve shared memory region (addr=01AA0000) for child 00000538: error code 487
2016-11-05 07:59:42 CET LOG: n'a pas pu exécuter le processus autovacuum worker : No error
Je précise que si je copie le répertoire \data sur un autre poste (qui est en 64 bits avec PostgresQL en 32 bits) je peux accéder aux données.
La base n'est donc pas endommagée
Sur le poste incriminé, j'ai d'abord eu le problème avec PostgreSQL 9.3
Je l'ai complètement désinstallé, j'ai supprimé le répertoire des données, j'ai installé PG 9.5.5 et restauré une sauvegarde.
Et le problème est survenu à nouveau assez rapidement.
De temps en temps ça fonctionne et mon application démarre
Je pense à un problème de RAM vu qu'il s'agit d'une version 32 bits de l'OS mais j'aimerais m'assurer que ce n'est pas autre chose
Avez-vous eu ce type d'erreur et pouvez-vous m'en dire plus à son sujet ?
Hors ligne
Bonjour,
Avec http://forums.postgresql.fr/viewtopic.p … 284#p24284 et http://forums.postgresql.fr/viewtopic.php?id=3995, cela fait fait maintenant 3 personnes qui ont le même problèmes à quelques jours d'intervalle. Tout porte à croire que le problème vient d'une récente mise à jour de windows. Je vous conseille de vous rapprocher du support microsoft, et de leur demander si une mise à jour n'aurait pas changé le comportement de VirtualAllocEx().
Julien.
https://rjuju.github.io/
Hors ligne
Merci pour ta réponse
J'ai fait des recherches il y a une semaine sur le sujet et il n'y avait encore rien sur les forums.
C'est déjà une piste en tout cas, merci.
C'est vrai que PG fonctionnait très bien depuis plus d'un an sur ce poste.
Dans mon cas la réinstallation n'a rien donnée, j'ai eu le même problème avec la version 9.5.5 nouvellement installée
Par contre ce matin j'ai installé pour test la 9.6 sur ce poste et pour l'instant pas de problème remonté.
Pour ceux qui ont le problème : chez moi, le problème est présent uniquement sur un Windows 7 Pro 32 bits. Sur mon poste, en Windows 10 Pro 64bits, je n'ai pas eu de soucis
Hors ligne
Ce problème est également discuté sur la mailing list pgsql-bugs (https://www.postgresql.org/message-id/f … gresql.org).
Comme indiqué par Michael, une des modifications apportée récemment concerne l'activation par défaut de l'ALSR sur windows 7 et windows 2008R2 (https://support.microsoft.com/en-us/kb/2639308). Pouvez-vous vérifier que l'ALSR est bien activé ?
Julien.
https://rjuju.github.io/
Hors ligne
Bonjour
Comment connaître le status de l'ASLR sur Windows 7 ?
La seule info que j'ai trouvée c'est comment le désactiver (https://ulbright.com/2013/11/06/disable … windows-7/)
Cette clé n'est pas présente chez moi, ça veut dire que l'ASLR est activé ?
Hors ligne
En visualisant par Process Explorer, ASLR n'est pas activé pour postgres.exe
J'utilise le build fourni par EntrepriseDB
Pour info, le même problème signalé en janvier 2014 sur Windows Server 2012 R2 : https://www.postgresql.org/message-id/B … 2F4@maumau
Hors ligne
Des informations supplémentaires ...
Suite au message de Mikael Wallén sur le forum PostgreSQL (https://www.postgresql.org/message-id/1 … sion.local) qui parle d'un éventuel lien avec F-Secure.
Il s'avère effectivement que mes deux postes qui ont le problème utilisent F-Secure.
J'ai donc fait un test sur une VM avec Windows 7 pro 32bits sur lequel PG fonctionne bien : j'ai installé la version de test de F-Secure.
Ça n'a pas loupé : après redémarrage on voit immédiatement le problème dans le log de PG. Ensuite les applis clientes plantent une fois sur 5 environ.
D’après le message de Mikael il se pourrait que Windows Defender soit aussi concerné. Là par contre je ne reproduis pas le problème.
Hors ligne
Bonjour,
Toutes les machines ayant le code erreur 487 sont effectivement équipées de FSecure. Cependant j'ai une machine 64 bits avec FSecure non connectée au réseau d'entreprise qui ne présente pas le bug.
Je pense que tout dépend quand est lancé Postgresql au démarrage de la machine par rapport à un service (FSecure ?)
J'ai effectué différents essais sur différentes machines en lançant le service Postgresql en'Automatique (Début différé)'. Par défaut le lancement s'effectue au bout de 2 minutes.
Certaines fois cela suffit pour les messages d'erreurs n'apparaissent plus, d'autres il faut que je rallonge le début différé (via la balise DelayedAutoStart dans la base de registre) d'une minute.
Si cela peut aider...
Hors ligne
Merci pour le retour
De mon côté j'ai fait aussi d'autres tests.
A confirmer, mais chez moi ça colle : quand je désactive le module DeepGuard de FSecure je n'ai plus le problème.
J'ai fais une dizaine de démarrages avec, une dizaine sans et visu du log PG juste après.
Hors ligne
Bingo. Effectivement la machine qui ne pose pas de problème a la fonction 'DeepGuard' désactivée.
Merci pour les informations.
Hors ligne
