Vous n'êtes pas identifié(e).
Alors quand-même pour ceux qui comprennent pas tout comme moi, il existe un dépôt spécial sql sur lequel il ya plus de choix de versions :
Pour rpm :
Il doit falloir un dépôt particulier sinon une recherche avec dnf ne me rtourne aucun résultat sur pg_dump ou restore.
Ha! Ben, faudrait que je consacre une machine un jour qui serve serveur aussi conservatrice que notre sainte église apostolique romaine. Comme ça au moins, les choses seront immuables.
Ceci étant je conçois qu'effectivement ces merveilleux outils genre posgresql ne sont pas conçus pour ètre utilisés par tout le monde, mais enfin, faut avouer que rien n'est simple dans tout cela. On pourrait imaginer un paquet pg_dump / pg_restore indépendant, que l'on pourrait choisir à la version que l'on veut sans réinstaller tout le serveur je pense....
Bon enfin donc la meilleure solution de fonctionne pas avec l'installateur de EDB qui reste bloqué sur l'initialisation du cluster. Et je ne vois pas comment l'aider à installer son cluster. Contrariant n'est-il pas ? Après un oeil sur le répertoire que je lui avais assigné durant l'installation pour les données, je m'aperçois qu'il n'est pas vide. Du coup je relance
su -c './postgresql-9.6.10-2-linux-x64.run' Et hop, ça fonctionne.
j'avais vaguement essayé la deuxième solution mais je ne suis plus pourquoi la sauvegarde depuis pgadmin3 avait merdé et j'avais abandonné. Vais tenté de nouveau. Je vous tiens au jus.
Et alors la 3ième possibilité m'épate - ça se rapproche quand-même de mon petit commentaire ci-dessus. Comment peut-on faire cela ?
Bonjour,
Sur mon ancien Linux fedora j'avais un serveur 9.6.8 , sur la mageia postgres pg_restore (PostgreSQL) 9.6.7
Est-ce que cela suffit pour justifier de l'erreur ? Faut-il vraiment que j'installe la version 9.6.8 ?
En plus je ne comprend pas car mon message d'erreur me parle d'une version (1.13) .... ? Ce serait la version de quoi ça ?
Merci.
Bon j'ai refait une installation de postgres, revu postgres.conf qui contenait une erreur et ça tourne.
Le problème n'est pas résolu pour autant vu que je ne sais pas pourquoi et comment l'installation de départ à raté.
Merci pour votre aide.
En fait cela s'est fait tout seul, dans les paquets dépendants de wapt je suppose c'est en installant wapt. Il faut que je recommence l'installation du coup.
Ha! Ben y c'est curieux que dans les status il dise que le serveur est actif.
Ceci dit il doit manquer des choses vu que je n'ai pas de pg-ctl disponible (pg_config pg_conftool pg_createcluster pg_ctlcluster c'est tout)
Bonne idée. Pour le ps :
root 10606 9931 0 11:54 pts/0 00:00:00 su postgres
postgres 10607 10606 0 11:54 pts/0 00:00:00 bash
root 10748 10679 0 12:09 pts/0 00:00:00 su postgres
postgres 10749 10748 0 12:09 pts/0 00:00:00 bash
root 10906 10839 0 12:32 pts/0 00:00:00 su postgres
postgres 10907 10906 0 12:32 pts/0 00:00:00 bash
root 11156 11153 0 13:34 pts/0 00:00:00 su postgres
postgres 11157 11156 0 13:34 pts/0 00:00:00 bash
postgres 11486 11157 0 15:01 pts/0 00:00:00 ps -ef
postgres 11487 11157 0 15:01 pts/0 00:00:00 grep postgresEt oui j'ai redémarré le serveur.
Pourquoi y a-t-il autant de processus postgres ?
Bonjour,
Oui le serveur fonctionne :
systemctl status postgresql
● postgresql.service - PostgreSQL RDBMS
Loaded: loaded (/lib/systemd/system/postgresql.service; enabled; vendor preset: enabled)
Active: active (exited) since Mon 2018-04-09 13:11:08 CEST; 20min ago
Process: 11039 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
Main PID: 11039 (code=exited, status=0/SUCCESS)
Apr 09 13:11:08 debianwapt.lanadiere.local systemd[1]: Starting PostgreSQL RDBMS...
Apr 09 13:11:08 debianwapt.lanadiere.local systemd[1]: Started PostgreSQL RDBMS.Mais bon quand j'essaie de le lancer en étant "postgres" sur localhost ou sur l'adresse ip du serveur c'est apreil...
psql -h localhost
psql: could not connect to server: Connection refused
Is the server running on host "localhost" (::1) and accepting
TCP/IP connections on port 5432?
could not connect to server: Connection refused
Is the server running on host "localhost" (127.0.0.1) and accepting
TCP/IP connections on port 5432?Et voilà un extrait des fichier de configuration :
# TYPE DATABASE USER ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all trust
# IPv4 local connections:
host all all 127.0.0.1/32 trust
# IPv6 local connections:
host all all ::1/128 trust
# Allow replication connections from localhost, by a user with the
# replication privilege.
#local replication postgres trust
#host replication postgres 127.0.0.1/32 trust
#host replication postgres ::1/128 trust
#serveur debianwapt
host all all 10.111.31.78/16 md5#------------------------------------------------------------------------------
# CONNECTIONS AND AUTHENTICATION
#------------------------------------------------------------------------------
# - Connection Settings -
listen_addresses = '*' # what IP address(es) to listen on;
# comma-separated list of addresses;
# defaults to 'localhost'; use '*' for all
# (change requires restart)
port = 5432 # (change requires restart)Je viens tout juste de faire l'installation d'une distribution debian et de ,postgresql.
Après quand je vérifie si le port est ouvert sur le système avec nmap, il ne l'est pas alors qu'il devrait puisque postgresql est cencément là pour l'écouter. Doi donc y avoir un soucis avec postgres. D'ailleurs je n'ai aucun fichier de log dans /var/log/postgresql !
Merci de m'aider.
Merci. C'est vrai aussi que certaines de mes erreurs sont évidentes.
Donc...
psql -d "SIG" -c '\copy "Ouvèze".ouvrages ("NumOuv","NumOuvSPE","CodeBSS","X","Y","NomOuv") from 'test_copy.txt' WITH (FORMAT csv,DELIMITER ";",HEADER)'...marche bien. Sauf qu'il a fallu que je transforme mes coordonnées françaises en format numérique anglais avec un "." au lieu d'une "," pour les décimales. Faut que je trouve autre chose.
Je poste ici mais pas absoluement sûr d'avoir un pb de «quote"... on verra :
cat test_copy.txt
NumOuv;NumOuvSPE;CodeBSS;X-L2;Y-L2;NomOuv
1;2600109;2600109;838786,83757;1926632,23418704;"Prise dans L'Ouveze de sa source au Menon Canarde A 443"
ps\copy : erreur d'analyse sur « "Ouvèze.ouvrages\" »
ql -d "SIG" -c '\copy \"Ouvèze.ouvrages\" from 'test_copy.txt' WITH ((FORMAT csv, HEADER)'Voilà.Une «erreur d'annalyse» c'est pas bien parlant pour moi. Bon alors j'ai essayé avec "Prise dans L\'Ouveze de sa source au Menon Canarde A 443" pour voir ce que ça donne et c'est pareil.
La table :
CREATE TABLE "Ouvèze".ouvrages
(
"NumOuv" integer NOT NULL, -- Ce numéro d'ouvrage n'est pas unique pour une prise d'eau. Il est unique administrativement
"NumOuvSPE" character varying(20), -- id de pompage et non pas ID de prélèvement (évite les doublons)...
"CodeBSS" integer, -- référence de la base de données BSS
"X-L2" point, -- Coordonnée géographique, projection Lambert 2.
"Y-L2" point, -- Coordonnée géographique, projection Lambert 2.
"NomOuv" character varying(255)[]
)
WITH (
OIDS=FALSE
);Qu'est-ce que vous en dites ? Merci.
Oui merci en effet suite à un échange sur IRC c'est ce qu'il ressort.
Ceci dit, repasser à la version de potgis 2.2 n'est pas possible pour l'instant : https://redmine.postgresql.org/issues/2570
Bonjour,
Je viens de mettre à jour mon système (fedora 26), et j'ai, du coup postgresql 9.6 et postgis 2.3, alors qu'avant, j'avis respectivement 9.5 et 2.2.
J'avais des «tablespace» pour les bdd geo et pour la compta. Ce qui m'intéresse c'est la compta car pas sauvegardée depuis un mois.
Donc une fois tout installé, j'ai tenté ceci :
sudo postgresql-setup --upgrade --unit postgresql@ancien --new-systemd-unit --datadir /var/www/bdd/postgres/9.5 --port 5433Ce qui ne fonctionne pas à cause de la nouvelle version de postgis
Performing Consistency Checks
-----------------------------
Checking cluster versions ok
Checking database user is the install user ok
Checking database connection settings ok
Checking for prepared transactions ok
Checking for reg* system OID user data types ok
Checking for contrib/isn with bigint-passing mismatch ok
Checking for roles starting with 'pg_' ok
Creating dump of global objects ok
Creating dump of database schemas
OpenConcerto
evp
postgres*failure*
Consult the last few lines of "pg_upgrade_dump_13336.log" for
the probable cause of the failure.
Failure, exiting
et le pg_upgrade_dump_13336.log contient ceci :
command: "/usr/bin/pg_dump" --host '/var/lib/pgsql' --port 5433 --username 'postgres' --schema-only --quote-all-identifiers --binary-upgrade --format=custom --file="pg_upgrade_dump_13336.custom" 'dbname=postgres' >> "pg_upgrade_dump_13336.log" 2>&1
pg_dump: [programme d'archivage (db)] échec de la requête : ERROR: could not access file "$libdir/postgis-2.2": No such file or directory
pg_dump: [programme d'archivage (db)] la requête était : SELECT pg_catalog.pg_get_viewdef('104728'::pg_catalog.oid) AS viewdef
command: "/usr/bin/pg_dump" --host '/var/lib/pgsql' --port 5433 --username 'postgres' --schema-only --quote-all-identifiers --binary-upgrade --format=custom --file="pg_upgrade_dump_13336.custom" 'dbname=postgres' >> "pg_upgrade_dump_13336.log" 2>&1
pg_dump: [programme d'archivage (db)] échec de la requête : ERROR: could not access file "$libdir/postgis-2.2": No such file or directory
pg_dump: [programme d'archivage (db)] la requête était : SELECT pg_catalog.pg_get_viewdef('104728'::pg_catalog.oid) AS viewdef
Manifestement, ça plante à cause de la version de postgis qui ne correspond pas. Or, les bdd qui en dépendent ne m'intéressent pas.
Est-il possible de lui dire : fait le job en focalisant uniquement sur «OpenConcerto» ?
Merci, et bonne journée.
En fait la commande exacte est la suivante :
psql -d OpenConcerto --command='\copy \"schema50\".\"ACOMPTE\" from 'ACOMPTE.txt' WITH (FORMAT csv, HEADER, NULL '\N')'Le problème est que j'avais omis de protéger les " par un \. Cependant il y a erreur qunad-même en plus parce que l'erreur, avec la commande ci-dessus reoturne :
\copy: error de procesamiento en «"schema50\"»
Par ailleurs en mettant des guillemets douibles pour encadrer la commande ça marche :
psql -d OpenConcerto --command="\copy \"schema50\".\"ACOMPTE\" from 'ACOMPTE.txt' WITH (FORMAT csv, HEADER, NULL '\N')"Merci.
Non c'est moi qui me suis mal exprimé ... décidément :-)
J'avais bien compris et c'est ce que j'ai fait (d'où le Ps). Par contre j'avais compris de tenter aussi en transformant les \N en NULL.
Bref pour être clair j'ai tenté la commende sans la clause FORCE_NOT_NULL avec \N ou NULL mais dans les deux cas ça marche pas.... ce qui me fait susp0ecter que soucis est ailleurs.
Non ça ne marche pas après modif des \N en NULL
ERROR: invalid input syntax for type timestamp: "NULL"
CONTEXTO: COPY ACOMPTE, line 2, column MODIFICATION_DATE: "NULL"
Ps : la commande que j'ai lancé est psql -d mabdd --command='\copy "schema"."ACOMPTE" from '~/Sauvegardes/Base/mabdd/ACOMPTE.txt' WITH (FORMAT csv, HEADER, NULL '\N')'
Oui oui je comprend bien mais dans la première version que j'avais faite j'utilisais FORCE_NULL qui est censé, si j'ai bien compris, trouver une concordance entre \N et une valeur qui aille pour le type timestamp mais j'ai la même erreur alors je ne sais pas trop comment tourner le problème.
Bonsoir,
Bon j'ai fait un script sur mon linux préféré pour récupérer tous les fichiers sql d'un répertoire donné et les exécuter dans psql (c'est du supra simple avec find et ça marche très bien).
Ensuite, il faut mettre des valeurs dans les tables, et là j'ai les fichiers.txt qui vont bien.
sauf que voilà....
psql -d mabdd --command='\copy "schema"."ACOMPTE" from '~/Sauvegardes/Base/mabdd/ACOMPTE.txt' WITH (FORMAT csv, HEADER, NULL '\N',FORCE_NOT_NULL ("MODIFICATION_DATE","CREATION_DATE"))'me retourne ceci...
ERROR: invalid input syntax for type timestamp: "\N"
CONTEXTO: COPY ACOMPTE, line 2, column MODIFICATION_DATE: "\N"
Faudrait-il que je transforme tous les "\N" qui correspondent aux colonnes de tous les fichiers.txt ? Si c'est ça je ne suis pas rendu, mais c'est faisable.
Sauf que j'imagine qu'il y a bien mieux à faire ?
Voilà la tête d'un fichier txt :
ID,ID_SALARIE,MONTANT,ID_MOUVEMENT,ARCHIVE,ORDRE,MODIFICATION_DATE,ID_USER_COMMON_MODIFY,ID_USER_COMMON_CREATE,CREATION_DATE
"1","1","0","1","0","0.00000000",\N,"1","1",\N
Et la table....
CREATE TABLE "ACOMPTE" (
"ID" serial,
"ID_SALARIE" int DEFAULT 1 ,
"MONTANT" real DEFAULT 0 ,
"ID_MOUVEMENT" int DEFAULT 1 ,
"ARCHIVE" int DEFAULT 0 ,
"ORDRE" DECIMAL(16,8) ,
"MODIFICATION_DATE" timestamp(6) ,
"ID_USER_COMMON_MODIFY" int DEFAULT 1 ,
"ID_USER_COMMON_CREATE" int DEFAULT 1 ,
"CREATION_DATE" timestamp(6) ,
PRIMARY KEY ("ID")) ;
Merci pour votre aide
Heu... hem....
Mais alors les tablespace et les schémas ... ? Quels avantages ou inconvénients si ce n'est qu'avec des tablespaces on pointe un répertoire spécifique dans le système de fichiers de l'OS et que les schémas me semblent un peu plus virtuels ?
Merci.
En effet je ne l'avais pas compris comme cela.
Ps : y a un tag "résolu" qq part ?
Haaaa ok! Ben du coup je ne trouve pas ça clair :
D'un côté il est dit que l'on peut mettre n'inporte quoi en .conf dans le répertoire mais en fait c'est n'importe quoi en .conf qui concerne uniquement les commandes que peut comporter un postgresql.conf
Merci.
Désolé, j'ai dû laisser cette question de côté un moment, mais j'y reviens donc parce que je ne comprend pas...
Dans le fichier postgresql.conf il y a bien le paramètre "hba_file =" que l'on peu renseigner et faire pointer sur n'importe quel fichier de n'importe quel répertoire.
Après je ne sais pas ce que vous voulez dire par
car un fichier pg_hba.conf ne peut pas être inclus dans un fichier postgresql.conf.
Mais mon pg_hba n'est pas inclus dedans, c'est un fichier à part, mais qui se trouve dans le même répertoire le postgresql.conf personnalisé. Lequel répertoire fait l'objet de la valeur attribuée à include_dir dans le postgresql.conf qui est dans /etc/postgres
Il n'y a donc pas de pg_hba inclus dans aucun des postgresql.conf
Il y a juste un répertoire qui regroupe tout les fichiers de config perso : postgresql.conf ; pg_hba.conf ; pg_ident.conf comme stipulé dans la remarque '# include files ending in '.conf'' qui explique à quoi sert include_dir.
Pardon j'ai voulu clarifier l'ensemble et ai repris mon précédent post...
Non c'est tel que je l'ai écris là et c'est bien le paramètre hba_file que je positionne le reste est commenté. Par contre oui ça ne fonctionne pas quand il est dans le répertoire pointé par include_dir mais il est dit que le répertoire de include_dir
# include files ending in '.conf'
donc aussi le pg_hba.conf
Pour la modif je le fais soit à la main avec un éditeur geamy ou nano dans la console, soit avec pgadmin.
le fichier /etc/postgresql/9.5/main/postgresql.conf
#------------------------------------------------------------------------------
# FILE LOCATIONS
#------------------------------------------------------------------------------
# The default values of these variables are driven from the -D command-line
# option or PGDATA environment variable, represented here as ConfigDir.
data_directory = '/var/lib/postgresql/9.5/main' # use data in another directory
# (change requires restart)
hba_file = '/etc/postgresql/9.5/main/pg_hba.conf' # host-based authentication file
# (change requires restart)
ident_file = '/etc/postgresql/9.5/main/pg_ident.conf' # ident configuration file
# (change requires restart)
# If external_pid_file is not explicitly set, no extra PID file is written.
external_pid_file = '/var/run/postgresql/9.5-main.pid' # write an extra PID file
.../...
include_dir = '/var/www/bdd/postgres/conf'Maintenant /var/www/bdd/postgres/conf/postgresql.conf qui fonctionne avec le même pg_hba.conf ci-dessous contient :
hba_file = '/var/www/bdd/postgres/9.5/pg_hba.conf' Il ne précise donc pas un répertoire de données particulier.... ce qui suppose que les données sont dans /var/lib/postgresql/9.5/main , et donc pas là où il y a le pg_hba.conf qui fonctionne...
Et le pg_hba.conf qui fonctionne, /var/www/bdd/postgres/9.5/pg_hba.conf contient :
# Database administrative login by Unix domain socket
local all postgres trust
# TYPE DATABASE USER ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all md5
# IPv4 local connections:
host all all 127.0.0.1/32 md5
# IPv6 local connections:
host all all ::1/128 md5
# Allow replication connections from localhost, by a user with the
# replication privilege.
#local replication postgres peer
#host replication postgres 127.0.0.1/32 md5
#host replication postgres ::1/128 md5
host all all 109.190.174.178/32 md5La dernière ligne que j'ai mise est censée me permettre d'accéder au serveur depuis l'extérieur (c'est l'adresse de mon modem, sur lequel j'ai configurer une redirection de port mais ça ne marche pas - c'est un autre problème).
Quand je mets ce fichier dans /var/www/bdd/postgres/conf/ j'obtient les erreurs suivantes :
The PostgreSQL server failed to start. Please check the log output:
LOG: syntax error in file "/var/www/bdd/postgres/conf/pg_hba.conf" line 85, near token "postgres"
LOG: syntax error in file "/var/www/bdd/postgres/conf/pg_hba.conf" line 90, near token "all"
LOG: syntax error in file "/var/www/bdd/postgres/conf/pg_hba.conf" line 92, near token "all"
LOG: syntax error in file "/var/www/bdd/postgres/conf/pg_hba.conf" line 94, near token "all"
LOG: syntax error in file "/var/www/bdd/postgres/conf/pg_hba.conf" line 100, near token "all"
FATAL: configuration file "/etc/postgresql/9.5/main/postgresql.conf" contains errors Il me semble mais bon...
Alors je le lance avec postgres comme utilisateur, et le groupe postgres à les rwx sur le répertoire /conf (voir mon premier message).
L'erreur est "une erreur de syntax" pour chacune des lignes de pg_hba.conf qui mentionne un accès. Hors il n'y a pas d'erreur de syntaxe puisque le même fichier fonctionne parfaitement dans le répertoire des données.