Vous n'êtes pas identifié(e).
Merci pour toutes les informations.
Cependant les différents logs ne me permettent pas de conclure: d'après le dernier log il y a eu une restauration des bases de l'instance à l'état du 23-01 qui s'est bien passée. Je ne vois pas d'erreur qui explique pourquoi l'instance ne peut pas redémarrer. Mais ce dernier log ne comporte pas de traces de niveau DEBUG5: je ne suis pas sûr que c'est vraiment le bon log ???
Les logs ne sont pas horodatés: je suggère de rajouter "%m" dans le paramètre log_line_prefix "%m user=%u-database=%d-host=%h=> ' " dans $PGDATA/postgresql.conf et d'essayer de redémarrer l'instance et de voir si le fichier log est bien modifié avec le nouveau format de trace.
En comparant avec un démarrage d'instance PG version 10.11 sur CentOS 7.7.1908 et avec le même niveau de trace, la piste que je voie c'est un problème avec le processus logger:
user=-database=-host==> DEBUG: logger shutting downIl faut le contenu du dernier log dans $PGDATA/log et le fichier de configuration $PGDATA/postgresql.conf pour en savoir plus.
Le fichier $PGDATA/postmaster.pid est créé automatiquement au démarrage de l'instance PG et est supprimé automatiquement à l'arrêt de l'instance. Il ne faut pas le modifier ou le supprimer manuellement.
S'il n'est pas là, cela veut normalement dire que l'instance PG a été arrêtée.
Pour analyser votre problème, essayez de modifier dans $PGDATA/postgresql.conf le paramètre log_min_messages:
log_min_messages = debug5 Dans le shell, avec le compte postgres:
1. vérifiez bien que PGDATA pointe bien sur le répertoire de la base PG 10 et que PATH contient bien les exécutables PG10:
-bash-4.2$ echo $PGDATA
/var/lib/pgsql/10/data
-bash-4.2$ echo $PATH
/usr/pgsql-10/bin:/usr/pgsql-10/bin:/usr/lib64/qt-3.3/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin
-bash-4.2$ 2. essayer de démarrer l'instance avec :
pg_ctl start3. envoyez le contenu de la sortie de "pg_ctl start" et du log qui est dans $PGDATA/log qui doivent nous donner plus de détails si l'instance ne démarre pas.
Pouvez-vous afficher le contenu du dernier log dans $PGDATA/log ?
Quel est le résultat de la commande ls -al /var/lib/pgsql/10/data ?
Ce problème peut arriver s'il y a plusieurs versions PG installées avec plusieurs instances différentes dans des répertoires PGDATA différents et que vous essayer d'accéder à l'instance avec une mauvaise valeur de PGDATA.: il faut aussi vérifier le contenu des variables d'environnement PGDATA et PATH et qu'il n'y pas une autre instance PG démarrée.
C'est bien pg_restore 9.4.4 qui est utilisé. PostGIS est bien installé dans le schéma public.
On a aussi du retard dans la version de postGIS: j'ai réussi à faire fonctionner pg_restore en utilisant une version plus récente d'une fonction:
diff postgis--2.1.8.sql.26062019 postgis--2.1.8.sql
3461c3461
< AS 'SELECT $1 && $2 AND _ST_Intersects($1,$2)'
---
> AS 'SELECT $1 OPERATOR(@extschema@.&&) $2 AND @extschema@._ST_Intersects($1,$2)'et en modifiant le paramètrage de l'extension:
diff postgis.control.26062019 postgis.control
5c5,6
< relocatable = true
---
> relocatable = false
> schema = publicBonjour
Nous utilisons :
# select version();
version
---------------------------------------------------------------------------------------------------------------
PostgreSQL 9.4.4 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-16), 64-bit
(1 ligne)avec:
# select postgis_full_version();
NOTICE: Function postgis_topology_scripts_installed() not found. Is topology support enabled and topology.sql installed?
postgis_full_version
----------------------------------------------------------------------------------------------------------------------------------------------------
POSTGIS="2.1.8 r13780" GEOS="3.4.2-CAPI-1.8.2 r3921" PROJ="Rel. 4.9.1, 04 March 2015" GDAL="GDAL 1.9.2, released 2012/10/08" LIBXML="2.7.6" RASTER
(1 ligne)Nous exportons une base avec pg_dump et nous l'importons avec pg_restore.
Avant de lancer pg_restore, je supprime la base cible et je la recrée vide.
Le pg_restore est lancé sans option particulière:
pg_restore -v -d <base> -h <hostname> -p <port> -U <compte superuser> <fichier dump>.pg_restore a plusieurs erreurs du type suivant:
pg_restore: [programme d'archivage (db)] could not execute query: ERREUR: l'opérateur n'existe pas : public.geometry && public.geometry
LIGNE 1 : SELECT $1 && $2 AND _ST_Intersects($1,$2)
^
ASTUCE : Aucun opérateur ne correspond au nom donné et aux types d'arguments.
Vous devez ajouter des conversions explicites de type.
REQUÊTE : SELECT $1 && $2 AND _ST_Intersects($1,$2)
CONTEXTE : fonction SQL « st_intersects » durant « inlining »
La commande était : CREATE MATERIALIZED VIEW dr_vue_cons_geo_zone_batie_hors_zae AS
WITH zone_bati_hors_zae AS (
SELECT sbat.gid,
...
La base source et la base cible ont exactement la même version PostgreSQL et la même version de PostGIS.
On est bloqué sur cette erreur car la seule référence que j'ai trouvé pour ce type d'erreur est liée à des upgrades mais on ne fait pas d'upgrade.
Est-ce que quelqu'un a une piste ?
Merci.
Bonjour,
L'utilisation d'un outil en ligne comme SQL Fiddle permet d'utiliser une base de données sans avoir rien à installer à condition d'accepter les contraintes suivantes
- interface en anglais
- version utilisée qui date un peu
- pas de droits de type administrateur.
Vous pouvez essayer de passer les paramètres avec l'option -v de psql:
Exemple:
psql -a -vparam_b=true -vparam_i=123 -vparam_t="'titre rapport'" -f tv.sqlavec tv.sql:
select :param_b as "param_b";
select :param_i as "param_i";
select :param_t as "param_t";
\qL'exécution donne:
select :param_b as "param_b";
param_b
---------
t
(1 row)
select :param_i as "param_i";
param_i
---------
123
(1 row)
select :param_t as "param_t";
param_t
---------------
titre rapport
(1 row)
\q