Vous n'êtes pas identifié(e).
Pages : 1
bonjour,
j'ai un soucis avec pgbouncer: le datestyle par defaut de mon serveur postgresql 8.4 est ISO, Europeen. en connexion directe sur le port de postgresql (sans pgbouncer) j'ai la bonne date. cependant, lorsque je passe en connexion via pgbouncer, j'ai la date de toute mes base au format americain (MDY). Le date style change.
J'ai l'impression que pgbouncer impose son datestyle (ISO).
Comment faire pour le changer?
Merci d'avance
ps: je suis sous linux, redhat.
Dernière modification par gngassam (06/07/2010 12:07:38)
Hors ligne
Le datestyle n'est pas forcé dans la configuration de pgbouncer ?
C'est un des principaux exemples donnés dans la doc : http://pgbouncer.projects.postgresql.or … onfig.html
Marc.
Hors ligne
Si , cependant dans la doc on donne comme exemple "datestyle=ISO", or je souhaiterai plutot avoir un format ISO, European. Le soucis est que le datestyle diffère selon que je me connecte via le port pgbouncer ou directement sur le port d'une instance postgresql pour une meme base de données.
Hors ligne
Quel datestyle avez vous positionné dans la conf de pgbouncer ?
Dans la doc, ils donnent un exemple. rien ne vous interdit de positionner datestyle à ce que vous voulez.
Marc.
Hors ligne
datestyle=ISO, ce pendant quant je change datestyle=ISO,European (ex: mydb= host=10.1.132.39 dbname=mydb port=5436 datestyle=ISO,European), ca ne change pas en base. Je me demande si c'est la bonne notation?
Dernière modification par gngassam (06/07/2010 17:28:10)
Hors ligne
datestyle=ISO n'est pas pris en compte non plus ?
Marc.
Hors ligne
c'est la valeur par defaut quant je me connecte à la base par le port de pgbouncer.
Hors ligne
Ce n'est pas ce que vous dites dans le premier post. Vous dites que les bases sont en MDY. Pouvez vous reexpliquer l'ensemble ?
Marc.
Hors ligne
si, juste que:
Il sagissait de faire une migration du serveur de production (postgresql 8.1.15 sur redhat el5 linux). Le temps de reprise d'activité accordé était de 5mn (perte de données à 0%). Cependant une migration complète des bases de prod m'aurait pris pas moins de 4 heures.
Alors, j'ai dumpé les bases 8.1.15, et je les ai restaurées sur un serveur de PRA en 8.4.
J'ai ensuite configurer pgbouncer sur le serveur de prod en utilisant le port de l'ancienne 8.1.15 (5436) en le redirigent vers le serveur de PRA (8.4). Ma durée d'indisponibilité a ainsi pris le temps de stopper l'instance 8.1.15 et de démarrer pgbouncer (soit 1mn). Ainsi je n'ai pas été forcé de reparamétrer et de recompiler mes applis.
Au final, j'ai pu reinstaller en toute quietude la 8.4 en prod et le mettre a jour avec slony (master: serveur de PRA, slave:serveur de prod), et ensuite j'ai fait la bascule en prod (en arretant pgbouncer, et desactivant slony), ceci sans toucher à mes applis, la restauration de plusieurs centaines de GIGA de données a donc semblé prendre 3mn (au vu des utilisateurs).
OK, maintenant que tout est claire le soucis qu'ont rencontré les applis pendant que pgbouncer était actif (sur la prod), est que, lorsque je me connectais sur la prod, donc à partir du port de pgbouncer (comme le font les applis), j'avais un problème d'INSERT des dates (incompatibilité de format). Show datestyle me donnait ISO,MDY, et à partir du serveur de PRA(configuré en ISO,European) SHOW datestyle me donnait ISO,DMY. Pourquoi ces différences pour une meme base? sachant que le datestyle de pgbouncer était ISO (je ne sais pas comment en configurer d'autre)?
Voila Marc,
c'est important pour moi de comprendre vu que j'ai quatre autre migration à faire!
Hors ligne
Je viens de tenter de reproduire ce problème sans succès. Je n'ai jamais eu MDY, sauf à le forcer explicitement.
Si tu veux éviter tout problème, tu peux toujours forcer datestyle=ISO,DMY dans la ligne de déclaration de base dans pgbouncer.
Marc.
Hors ligne
Merci marc,
peut etre est-ce parceque j'ai modifié le datestyle dans le postgresql.conf et que j'ai reloadé la conf de postgresql sans relancer pgbouncer. Qu'en pense tu, pgbouncer a t'il besoin d'être redémarré pour prendre en compte la nouvelle conf de postgresql?
je ne peux pas faire ces essais en prod.
Hors ligne
Très possible : je ne pense pas que le reload modifie le datestyle des sessions déjà montées. Ce qui entraîne que les sessions que pgbouncer a déjà dans son pool garderaient leur paramétrage.
Marc.
Hors ligne
Ok, merci marc,
je fais un ticket à l'exploit pour le redémarrage de pgbouncer et je te tiens informé.
Hors ligne
Marc,
c'était tout à fait ca, après avoir redémarré pgbouncer, il a effectivement récupéré les paramètres de postgresql.
Merci pour ta réactivité.
Hors ligne
Pages : 1
