Vous n'êtes pas identifié(e).
Bonjour.
Après discussion avec l'administrateur système, nous nous sommes rendus compte que le port 5432 n'était ouvert que pour l'adresse IP de ma machine Ubuntu.
Bonjour,
Le message indique que psql n'a pas trouve d'instance pour essayer de tenter de s'authentifier. Cela peut vouloir dire que tout simplement les instances ne sont pas demarrees, ou le sont mais ecoutent sur un autre port, ou qu'un firewall bloque la connexion.
Résolu
Le port n'était ouvert que pour l'adresse IP de la machine qui se connectait
Bonjour.
J'ai 3 machines debian 12, une debian sid et une ubuntu 22.04 et un serveur de bases de données debian 12
Machines debian 12 :
postgresql-15/stable,stable-security,now 15.5-0+deb12u1 amd64 [installé, automatique]
postgresql-client-15/stable,stable-security,now 15.5-0+deb12u1 amd64 [installé, automatique]
postgresql-client-common/stable,now 248 all [installé, automatique]
postgresql-common/stable,now 248 all [installé, automatique]
Machine Ubuntu :
postgresql-15/jammy-pgdg,now 15.5-1.pgdg22.04+1 amd64 [installé]
postgresql-client-15/jammy-pgdg,now 15.5-1.pgdg22.04+1 amd64 [installé, automatique]
postgresql-client-common/jammy-pgdg,now 256.pgdg22.04+1 all [installé, automatique]
postgresql-common/jammy-pgdg,now 256.pgdg22.04+1 all [installé, automatique]
Serveur PostgreSQL
postgresql-15/stable,stable-security,now 15.5-0+deb12u1 amd64 [installé, automatique]
postgresql-client-15/stable,stable-security,now 15.5-0+deb12u1 amd64 [installé, automatique]
postgresql-client-common/stable,now 248 all [installé, automatique]
postgresql-common/stable,now 248 all [installé, automatique]
postgresql/stable,now 15+248 all [installé]
Quand je lance :
psql -U postgres -h monserveur
la machine Ubuntu se connecte sans problème mais aucune machine debian ne se connecte avec le message:
psql: erreur : la connexion au serveur sur « monserveur » (IP serveur), port 5432 a échoué : Connexion terminée par expiration du délai d'attente
Le serveur est-il actif sur cet hôte et accepte-t-il les connexions ?
Le .pgpass est le même pour toute les machines
#connection automatique postgresql
*:*:*:postgres:motdepasse
postgresql.conf du serveur:
#------------------------------------------------------------------------------
# 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/15/main' # use data in another directory
# (change requires restart)
hba_file = '/etc/postgresql/15/main/pg_hba.conf' # host-based authentication file
# (change requires restart)
ident_file = '/etc/postgresql/15/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/15-main.pid' # write an extra PID file
# (change requires restart)
#------------------------------------------------------------------------------
# CONNECTIONS AND AUTHENTICATION
#------------------------------------------------------------------------------
# - Connection Settings -
#listen_addresses = 'localhost' # what IP address(es) to listen on;
listen_addresses = '*'
# comma-separated list of addresses;
# defaults to 'localhost'; use '*' for all
# (change requires restart)
port = 5432 # (change requires restart)
pg_hba.conf du serveur :
# Database administrative login by Unix domain socket
local all postgres scram-sha-256
# TYPE DATABASE USER ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all peer
# IPv4 local connections:
#host all all 127.0.0.1/32 scram-sha-256
host all postgres 0.0.0.0/0 scram-sha-256
host all mathesar 0.0.0.0/0 scram-sha-256
# IPv6 local connections:
host all all ::1/128 scram-sha-256
# Allow replication connections from localhost, by a user with the
# replication privilege.
local replication all peer
host replication all 127.0.0.1/32 scram-sha-256
host replication all ::1/128 scram-sha-256
Quel système d'exploitation utilisez vous? Est-ce que vous lancez le script avec votre propre utilisateur ? Avez-vous vérifié les droits sur le fichiers (cf https://www.postgresql.org/docs/current … pass.html).
Bonjour.
Ma machine est sous Ubuntu Mantic mais avec PostgreSQL 15 et pour l'instant je teste la commande manuellement sous mon nom.
-rw------- 1 jerome.perez jerome.perez 967 oct. 30 10:46 .pgpass
J'ai essayé un simple psql
jerome.perez@Mamachine:~$ psql -h localhost -U postgres postgres
Mot de passe pour l'utilisateur postgres :
Par contre j'ai
jerome.perez@Mamachine:~$ $PGPASSFILE
bash: /home/jerome.perez/.pgpass: Permission non accordée
Résolu en enlevant -W de la commande
Bonjour
Je fais régulièrement un pg_dumpall de mon serveur de production et souhaite il'intégrer dans un script pour une exécution automatique.
J'utilise la commande
pg_dumpall -U postgres -W -c --if-exists --exclude-database=*_test | gzip -c > /var/lib/postgresql/15/bdd-save/postgres_$(date +%Y-%m-%d--%H-%M-%S).sql.gz
sur mon serveur en local
Je dois donc saisir le mot de passe pour chaque base de données.
J'ai donc crée un fichier .pgpass dans mon "home directory" contenant
*:*:*:postgres:motdepasse
et exporté le PGPASSFILE.
J'ai relancé la commande initiale pour vérifier si c'était bon mais on me demande toujours le mot de passe.
Y a t'il un moyen de régler ce problème?
Merci d'avance.
Aucune opération DDL (sauf TRUNCATE) n'est répliquée dans une réplication logique.
Quand je parle de wal_level : logical c'est le niveau de WAL de la réplication physique que j'ai mise en place, ce n'est pas celui d'une réplication logique par souscription.
Du coup les opérations DDl semblent bien prises en compte....ce qui m'arrange.
C'est noté!.
Encore merci
Merci pour votre réponse.
Je vais commencer par mettre en place une réplication continue de tout le cluster de production vers un serveur de réplication.
Mais je suppose qu'en dehors d'une réplication logique on ne peut pas répliquer les bases XXX sans les XXX_test si il y en a.
Est-ce que les drop sont répercutés en wal_level : logical?
Ce n'est toujours pas très clair. Voulez vous créer localement une base de données XXX_test à chaque fois depuis la base originale XXX, ou souhaitez-vous répliquer les données de chaque base vers 2 bases: une base identique et une base XXX_test ?
Dans l'idéal, je souhaiterais pouvoir répliquer chaque base vers 2 bases: une base identique et une base XXX_test que je pourrai bidouiller tranquillement. Sinon je pourrais me contenter de la version créer localement une base de données XXX_test à chaque fois depuis la base originale XXX avec XXX_test en lecture/écriture (dans ce cas, ça serait bien de pouvoir le faire plus facilement qu'à la main avec pg_dump, transfert du fichier vers le serveur test puis psql ou pg_restore)
Bonjour,
Voulez-vous maintenir la réplication une fois les écritures activées sur le serveur de test?
Bonjour.
Idéalement oui si la même instance me permet de faire des tests sur une copie des bases répliquées. Par exemple : avoir une base activite à jour et la possibilité de créer et travailler sur une base activite_test avec les données à jour.
Mais la priorité reste quand même de pouvoir travailler avec un cluster conforme à mon instance de production sans impact sur elle et de ne pas être obligé de détruire/reconstruire tout le cluster quand je veux repartir de quelque chose de propre.
Résolu par la séparation du serveur de test et de celui de réplication : mise en place d'une réplication physique et l'utilisation de pg_dumpalll une fois par mois et pg_dump pour les bases tests
Bonjour.
Je souhaite répliquer un cluster de production vers un serveur de test en mode lecture/écriture mais pas en mode master/master?
La réplication logique doit permettre de le faire.Mais le cluster contenant une dizaine de bases de données, ça veut dire que je vais devoir créer une dizaine de publications, une dizaine de souscriptions et autant de slots de réplication.
Et pour couronner le tout, certaines tables n'ont pas de clef primaire ce qui veut dire que je devrais les rajouter manuellement avant de mettre en place la réplication.
N'y aurait-il pas une possibilité plus globale du type pg_basebackup permettant de garder la cible en lecture/écriture?
Merci d'avance.
M...e mais merci
Je vais voir si je peux faire ça avec une vm windows car j en'ai plus d'ordinateur windows sous le coude.
Bonjour.
Suite à un crash Windows, j'ai récupéré des bases de données PostgreSQL créées sous Windows que j'aimerai récupérer sous linux.
J'ai donc recopié les répertoires base et global dans mon répertoire main mais les bases ont pour locale French_France.1252 et évidemment c'est fr_FR.utf8 sur mon linux et mon postgresql.
Y a t'il un moyen de récupérer ces bases?
Merci d'avance.
Résolu en utilisant pg_dumpall et en remplaçant les collations LATIN par fr_FR.UTF8 dans le fichier sql avant de l'exécuter
Bonjour.
Je conçois, développe et administre (plus ou moins) des bases de données PostgreSQL(15.3).
Ayant un poste de travail Windows, un serveur de Bases de données sous debian 11 et un futur serveur test de bases de données sous debian 12.
Pour ne pas avoir à faire des sauvegarde/restauration à tire-larigot, j'aimerais mettre en place une réplication en cascade en utilisant uniquement des outils gratuits (idéalement ceux de PostgreSQL).
J'utilise la même version PostgreSQL sur tous mes systèmes.
Je souhaite donc savoir si comme je le crains il n'y a que la réplication logique qui me permette de le faire ou si il y a un autre moyen qui (outil) qui permette de le faire tout en offrant la possibilité de basculer un esclave en maître en cas de problème?
Merci d'avance.
J'ai installé postgresql sur un linux debian 11 et je me retrouve avec des cibles en double quand je fais un
sudo apt update
...
W: La cible DEP-11-icons (main/dep11/icons-64x64.tar) est spécifiée plusieurs fois dans /etc/apt/sources.list.d/pgdg.list:1 et /etc/apt/sources.list.d/postgresql.list:1
W: La cible Contents-deb (main/Contents-amd64) est spécifiée plusieurs fois dans /etc/apt/sources.list.d/pgdg.list:1 et /etc/apt/sources.list.d/postgresql.list:1
W: La cible Contents-deb (main/Contents-all) est spécifiée plusieurs fois dans /etc/apt/sources.list.d/pgdg.list:1 et /etc/apt/sources.list.d/postgresql.list:1
J'ai effectivement deux fichiers dans sources.list
/etc/apt/sources.list.d
$ ls -la
total 16
drwxr-xr-x 2 root root 4096 23 mai 18:12 .
drwxr-xr-x 7 root root 4096 22 mai 11:33 ..
-rw-r--r-- 1 root root 63 27 avril 11:35 pgdg.list
-rw-r--r-- 1 root root 120 27 avril 15:01 postgresql.list
dans postgresql.list j'ai :
deb [signed-by=/usr/share/keyring/postgresql-keyring.gpg] https://apt.postgresql.org/pub/repos/apt/ bullseye-pgdgd main
et dans pgd.list :
deb http://apt.postgresql.org/pub/repos/apt/ bullseye-pgdgd main
Est-ce que je dois garder les deux et continuer à avoir ce message ou il y a un moyen d'éviter ce problème ?
merci rjuju, je ne pensais pas que ça fonctionnait, j'aurais dû essayer avant.
Pas de soucis c'est bien une valeur par défaut car l'utilisateur peut saisir une autre année à l'insertion.
ça serait l'idéal mais je ne vois pas comment afficher l'année en cours comme valeur par défaut en postgresql
en réfléchissant un peu, j'aurais dû y penser.
Par contre je n'y connais rien en PL/pgSQL mais je vais voir si je m'en sors avec quelque chose du style
if new.annee is null then new.annee = select date_part('year', now()) endif;
dans ma fonction
Bonjour.
Je n'ai jamais eu besoin de travailler avec les triggers mais là, je dois mettre en place un trigger qui rempli un champs smallint vide avec l'année en cours.
Je souhaite donc intégrer la requête update table set annee = select date_part('year', now()) where annee is null dans un trigger after insert or update mais je ne sais pas comment faire?
Quelqu'un serait-il susceptible de m'aider?
Merci d'avance.
Résolu en mettant default = date_part('year', now())
Après plusieurs tentatives, ça a finalement fonctionné sans que je fasse quoi que ce soit.
Désolé.
Cette discussion peut être supprimée.
Bonjour.
J'ai une base de données stockée sur PostGreSQL 10 je fais une sauvegarde par pgadmin en .backup mais quand je restaure, ça ne fonctionne à cause de problèmes de création d'index qui ne fonctionnent pas à cause de clefs qui seraient dupliquées ou de clefs primaires multiples. Y a t'il un moyen de contourner ce problème car c'est une grosse base de données avec plusieurs schémas et de nombreuses tables et je ne me sens pas de tout reprendre pour virer les données qui sont incorrectes.
Cette requête marche effectivement bien aussi sauf si un même individu est aperçu dans une autre troupe entre la première et la dernière observation...mais ça c'est une autre histoire ;-)
SELECT ind.name as "Name"
, ind.sex as "Sex"
, S1.date as "First observation"
, S1.troop_ID as "Troop FirstObs"
, S1.present as "Present FirstObs"
, S2.date as "Last observation"
, S2.troop_ID as "Troop LastObs"
, S2.present as "Present LastObs"
FROM individuals as ind, sightings S1, sightings S2
WHERE
(
S1.individual_ID = ind.individual_ID
AND S2.individual_ID = ind.individual_ID
AND S2.individual_ID = S1.individual_ID -- ajout de la transitivité au cas où
)
AND NOT EXISTS
(SELECT 1 FROM sightings as S1b WHERE S1.date > S1b.date and S1.individual_ID = S1b.individual_ID )
AND NOT EXISTS
(SELECT 1 FROM sightings as S2b WHERE S2.date < S2b.date and S1.individual_ID = S2b.individual_ID )
order by ind.name
, S1.date
, S2.date
;
Merci
Merci, c'est bon, j'ai retrouvé tous les enregistrements MariaDB avec la requête :
SELECT distinct
first_value(name) OVER w as "Name FirstObs",
first_value(sex) OVER w as "Sex FirstObs",
first_value(is_dead) OVER w as "Dead FirstObs",
first_value(troop_ID) OVER w as "Troop FirstObs",
first_value(date) OVER w as "First observation",
first_value(present) OVER w as "Present FirstObs",
last_value(name) OVER w as "Name FirstObs",
last_value(sex) OVER w as "Sex LastObs",
last_value(is_dead) OVER w as "Dead LastObs",
last_value(troop_ID) OVER w as "Troop LastObs",
last_value(present) OVER w as "Present LastObs",
last_value(date) OVER w as "Last observation"
FROM individuals, sightings
where sightings.individual_ID = individuals.individual_ID
WINDOW w AS (PARTITION BY sightings.individual_ID, sightings.troop_ID ORDER BY name,date ROWS between unbounded preceding and unbounded following)
car un individu peut avoir été observé dans une troupe ou une autre à des dates différentes
Le S1.troop_id dans le group by est lié au message d'erreur la colonne S1.troop_id doit apparaître dans la clause GROUP BY ou doit être utilisé dans une fonction d'agrégat tout comme tous les champs autres que ind.name ou min/max.
Sinon je viens de me rendre compte que les données ne s'étaient pas correctement exportées de MariaDb quand il y avait plus de 1000 enregistrements dans une table.
Je relance l'exportation et l'importation et relance la requête avec fenêtrage.