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 » pg_upgrade postgres 9.3 vers 10.5 » 19/09/2018 11:29:20

Bonjour

J'ai un peu avancé

Le début de la problématique :

J'avais mis en trust uniquement l'ipv4  or pg_upgrade résout localhost en ipv6

Après avoir mis trust sur mes ipv4 je me retrouve avec une autre problématique

dans mon pg 9.3
Installé avec l'installeur d'entreprisedb
Le compte de création s'appelait postgres
J'avais importé une sauvegarde provenant d'un pg_dumpall
Le souci c'est que sur cette sauvegarde le compte d'installation était un compte root
J'ai bien ajouté le compte postgres en superuser

Mais pg_upgrade refuse de faire l'upgrade avec un compte autre que celui d'installation

Du coup j'ai un cluster qui a comme compte d'installation root
et le nouveau le 10.5 qui a postgres ...

Il faut que je désinstalle la 10.5 et trouve comment spécifier un compte dans l'installeur d'entreprise DB

#2 Général » pg_upgrade postgres 9.3 vers 10.5 » 18/09/2018 09:47:53

Brackis
Réponses : 2

Bonjour à tous

Après mes changements de postes hier j’essaie de m'attaquer à la mise à jour de postgre de 9.3 vers 10.5.

Je l'avais fait une fois dans le passé sans trop de souci mais là j'ignore pourquoi je bloque

La situation :
- Poste windows 10 pro avec un seul compte qui est administrateur
- postgres 9.3 isntallé sur le port 5432
- postgres 10.5 sur le port 5433
- Les 2 instances ont un role postgres super_user avec le même mot de passe
- mes 2 pg_hba.conf sont en trust host    all             all             127.0.0.1/32            trust
- j'ai même mis un pgpass




et pourtant systématiquement je me retrouve avec l'erreur suivante :


pg_upgrade run on Tue Sep 18 09:46:05 2018
-----------------------------------------------------------------

Exécution de tests de cohérence
-------------------------------
Checking cluster versions                                   ok

échec de la connexion à la base de données : fe_sendauth: no password supplied
n'a pas pu se connecter au postmaster source lancé avec la commande :
"C:\Program Files\PostgreSQL\9.3\bin/pg_ctl" -w -l "pg_upgrade_server.log" -D "c:\Program Files\PostgreSQL\9.3\data" -o "-p 5432 -b " start



Je ne comprends pas car si je lance moi même la commande pg_ctl dans mon invite de commande, elle fonctionne bien.

Les autres binaires se connectent sans problème pg_dump psql etc..

Auriez vous une piste pour moi ?

Cordialement

#3 Re : Général » Migration postgres 9.3 windows » 17/09/2018 12:15:36

C'est effectivement la raison

quand je copie un dossier que se soit entre 2 machine ou même au sein de la même machine les autorisations du comptes SERVICE RESEAUX ne suivent pas.

Un peu agacant

#4 Général » Migration postgres 9.3 windows » 17/09/2018 11:37:52

Brackis
Réponses : 2

Bonjour à tous

Je rencontre un petit problème que je n'arrive pas à expliquer.

Notre application utilise encore postgresql 9.3.

Lors d'un changement de pc j'ai le souci suivant

J'installe postgre sur le nouveau pc (avec l'installeur d'entrepriseDB)
Le service windows utilise comme compte de connexion par défaut le compte SERVICE RÉSEAU (comme sur le poste d'origine)

Je fais une copie à froid de mon ancien poste (l'intégralité du dossier DATA)

A la suite de çà impossible de démarrer le service j'ai un problème de droit pour créer le fichier postmaster.pid

Si je fais un démarrage manuel
".\pg_ctl.exe -D ..\data\ -w Start"

Pas de souci tous est en ordre

Si je change le compte de connexion dans les service windows pour mettre "système local"
Cà fonctionne


Si je prend le contenu du data d'origine (et pas le dossier) et que je le met dans le dossier DATA d'arrivé là çà fonctionne

Sauriez vous m'expliquer ce phénomène ?



Cordialement

#5 Re : Général » Problème d'extinction et de démarrage du service windows postgresql » 05/10/2015 14:35:46

merci pour la réponse sur le logging collector
(du coup faut qu'on trouve un moyen de purger ces fichier de log qui se crée )

J'ai fais la modification pour nettoyer l'event viewer mais comme la machine est en production je ne peux pas la redémarrer j'aurais donc plus d'information demain matin.

Encore merci pour votre aide et vos conseils

#6 Re : Général » Problème d'extinction et de démarrage du service windows postgresql » 05/10/2015 11:27:52

ok je vais faire cette modification pour regarder çà.

Concernant les paramètres du service, ils sont correcte puisque dès que je coupe les procces postgres qui sont présent au démarrage, le service se lance sans aucun problème.

Par contre je ne comprend pas pourquoi mon event viewer est remplis comme çà alors que j'ai mis mon logging_collector à off

A t'on obligation de logguer quelque part ?

#7 Re : Général » Problème d'extinction et de démarrage du service windows postgresql » 05/10/2015 11:03:56

De ce que j'ai vu :

Dans l'observateur d’événement j'ai plusieurs erreur au moment du démarrage
une qui me dis que le serveur n'a pas pus démarrer dans les temps
une qui me dit qu'il ne peut pas démarrer car il y a déjà un postmaster.pid (normale puisqu'en fait il est démarré)
Et après plein plein plein d'information mais il y en à vraiment beaucoup beaucoup (trop)
j'ai l'impressions que pratiquement toutes les requêtes sont loggué das l'event viewer

#8 Re : Général » Autovacuum » 02/10/2015 09:15:59

Bonjour

Merci pour ces retours

dès lors j'ai une dernière question

ma fameuse table template alors qu'elle n'a jamais changé depuis son installation peut avoir après un ANALYZE plusieurs "row dead"

Je croyais que ces ligne morte était due au opération de delete ?

#9 Général » Autovacuum » 01/10/2015 11:23:55

Brackis
Réponses : 4

Bonjour à tous

Je poste ici quelques questions en rapport avec l'autovacuum qui me laisse perplexe et j'aimerais avoir des éclaircissement si possible

Version de postgresql utilisé 9.3.9.
Environnement : Windows

1/ J'ai lu à plusieurs endroits que l'autovacuum était par défaut activé dans postgresql

Or j'ai aussi lu ceci :
"23.1.6. Le démon auto-vacuum
PostgreSQL ™ dispose d'une fonctionnalité optionnelle mais hautement recommandée appelée autovacuum, dont le but est d'automatiser l'exécution des commandes VACUUM et ANALYZE .Une fois activé , autovacuum vérifie les tables ayant un grand nombre de lignes insérées, mises à jour ou supprimées. Ces vérifications utilisent la fonctionnalité de récupération de statistiques ; du coup, autovacuum ne peut pas être utilisé sauf si track_counts est configuré à true. Dans la configuration par défaut, l'autovacuum est activé et les paramètres liés sont correctement configurés.
"

Ce texte en gras ne semble il pas indiqué le contraire ?

Sachant que dans le fichier de config installé par défaut toutes les ligne en relation avec l'autovacuum sont commenté

#------------------------------------------------------------------------------
# AUTOVACUUM PARAMETERS
#------------------------------------------------------------------------------

#autovacuum = on            # Enable autovacuum subprocess?  'on'
                    # requires track_counts to also be on.
#log_autovacuum_min_duration = -1    # -1 disables, 0 logs all actions and
                    # their durations, > 0 logs only
                    # actions running at least this number
                    # of milliseconds.
#autovacuum_max_workers = 3        # max number of autovacuum subprocesses
                    # (change requires restart)
#autovacuum_naptime = 1min        # time between autovacuum runs
#autovacuum_vacuum_threshold = 50    # min number of row updates before
                    # vacuum
#autovacuum_analyze_threshold = 50    # min number of row updates before
                    # analyze
#autovacuum_vacuum_scale_factor = 0.2    # fraction of table size before vacuum
#autovacuum_analyze_scale_factor = 0.1    # fraction of table size before analyze
#autovacuum_freeze_max_age = 200000000    # maximum XID age before forced vacuum
                    # (change requires restart)
#autovacuum_multixact_freeze_max_age = 400000000    # maximum Multixact age
                    # before forced vacuum
                    # (change requires restart)
#autovacuum_vacuum_cost_delay = 20ms    # default vacuum cost delay for
                    # autovacuum, in milliseconds;
                    # -1 means use vacuum_cost_delay
#autovacuum_vacuum_cost_limit = -1    # default vacuum cost limit for
                    # autovacuum, -1 means use
                    # vacuum_cost_limit

2/ Si effectivement l'autovacuum est activé par défaut

Pourquoi lorsque j'ouvre pgadmin et que je sélectionne certaine table il m'affiche un message d'aler m'indiquant qu'un vacuum est recommandé ?

Running VACUUM recommended
The estimated rowcount on the table "template" deviates significantly from the actual rowcount. You should run VACUUM ANALYZE on this table.
Instead of issuing a manual VACUUM ANALYZE command on this table (you can use the pgAdmin III maintenance menu for this), running VACUUM ANALYZE on a regular or automated basis should be considered. This can be achieved using a scheduler. PostgreSQL also supplies the autovacuum daemon, which will track changes made to the database and issue vacuum commands as required automatically. In most cases, autovacuum will be the best choice.

Sachant en plus que cette table dans mon exemple n'a pas changé d'un iota depuis la création de la table et l'insertion des lignes par défaut:

Désolé s mes questions peuvent paraitre bête je débute avec postgre

D'avance merci

Cordialement

Pied de page des forums

Propulsé par FluxBB