Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Ça peut aussi venir du fichier /etc/hosts.
Vérifiez que vous avez bien cette ligne:
127.0.0.1 localhostSi besoin la rajouter au fichier.
Peut-être que le fichier postgresql.conf fait la différence entre 127.0.0.1 et localhost, mais je ne pense pas.
À confirmer par les pros.
Bingo!
C'était une histoire d'ipV6!
N'utilisant ipv6, j'ai purement et simplement déactivé, pour ceux que ça intéresse j'ai suivi le tuto suivant (sous debian 9):
https://www.memoinfo.fr/tutoriels-linux … ur-debian/
Mille mercis, tout roule! 
J'avais effectivement essayé, mais l'erreur persiste.
Je suis perplexe, voici les lignes décommentées de mon pg_hba.conf.
J'ai masqué certaines informations (pour des raisons de sécurité) avec des *.
local all postgres peer
local all all peer
# IPv4 local connections:
host base2 user_fdw 127.0.0.1/32 md5
host all all 127.0.0.1/32 trust
host e****e a*****p 213.152.*.*/32 md5
host e****e g********e 37.187.*.*/32 md5
# IPv6 local connections:
host all all ::1/128 trustJ'ai bien redémarré mon serveur postgresql après modifications du fichier.
Je ne comprends pas ce que j'ai raté, mon fichier ressemble pourtant à l'exemple fournit par la doc officielle:
# Require SCRAM authentication for most users, but make an exception
# for user 'mike', who uses an older client that doesn't support SCRAM
# authentication.
#
# TYPE DATABASE USER ADDRESS METHOD
host all mike .example.com md5
host all all .example.com scram-sha-256Un dernier coup de pouce?!
EDIT: la connexion avec mot de passe fonctionne si je la force:
psql -h localhost -p 5432 base2 -U user_fdw -WDans le cas contraire (sans le -W), le mot de passe n'est pas demandé.
Je ne comprends pas ce qui m$§*e.
Merci pour ces investigations que j'aurais été bien incapable de mener.
Question suivante du coup, pour forcer l'usage d'un mot de passe pour l'utilisateur appelé par le FDW.
J'utilise la version 9.6 de postgresql sous debian.
Je pensais forcer l'usage en ajout la ligne ci-dessous (après la ligne trust car il me semble me souvenir que le fichier pg_hba est lu de haut en bas).
Mais rien n'y fait l'authentification via "trust" est toujours prioritaire.
host all all 127.0.0.1/32 trust
host base2 user_fdw 127.0.0.1/32 md5Auriez-vous une idée de ce que j'ai raté?
Pardon, j'ai oublié de préciser que j'avais déjà testé cette manip.
Dans ce cas l'erreur sur le count est la suivante:
select count(*) from fdw_base2.zone_etude;
ERREUR: password is required
DÉTAIL : Non-superuser cannot connect if the server does not request a password.
ASTUCE : Target server's authentication method must be changed.Merci pour la proposition en tous cas!
Bonjour,
Je ne suis pas sur de poster ma question dans la bonne section, désolé par avance si je me suis trompé.
Je rencontre une difficulté dans l'utilisation de postgresq_fdw .
Voici les éléments du problème:
Je dispose de deux bases de données.
La base 1 contient des observations naturalistes, la base 2 des zones d'étude.
Mon serveur autorise les connexions sans mot de passe pour tous les utilisateurs locaux à n'importe quelle base (voir extrait de pg_hba.conf + bas).
Je voudrais "avoir accès" (SELECT uniquement) à la table zone_etude de ma base 2.
J'ai mis en place une connexion via postgres_fdw pour avoir accès aux données.
Attribué les droits nécessaire et mappé les utilisateurs.
Voici ce que ça donne:
--création connexion
CREATE SERVER referentiel FOREIGN DATA WRAPPER postgres_fdw OPTIONS (host 'localhost', dbname 'base2', port '5432');
--mapping users
CREATE USER MAPPING FOR superuser
SERVER srv_base2 OPTIONS (USER 'user');
CREATE USER MAPPING FOR bidule
SERVER srv_base2 OPTIONS (USER 'user');
--création schéma et import données
CREATE SCHEMA fdw_base2 ;
GRANT USAGE ON SCHEMA fdw_base2 TO base1_groupe_concerne;
IMPORT FOREIGN SCHEMA schema_base2 LIMIT TO (zone_etude)
FROM SERVER srv_base2
INTO fdw_base2 ;
GRANT SELECT ON TABLE fdw_base2.zone_etude TO base1_groupe_concerne;La connexion fonctionne comme je le désire en tant que superuser:
select count(*) from fdw_base2.zone_etude;
count
-------
93
(1 ligne)Par contre en utilisateur simple:
select count(*) from fdw_base2.zone_etude;
ERREUR: password is required
DÉTAIL : Non-superusers must provide a password in the user mapping.Après quelques recherches sur le net je suis tombé sur cette information dans la documentation officielle postgresql ( https://docs.postgresql.fr/9.6/postgres-fdw.html ):
F.33.1. Options FDW de postgres_fdw
F.33.1.1. Options de connexionsUn serveur distant utilisant le wrapper de données distantes postgres_fdw peut avoir les mêmes options que celles acceptées par libpq dans les chaînes de connexion comme décrit dans Section 32.1.2, « Mots clés de la chaîne de connexion ». Cependant, ces options ne sont pas autorisées :
user et password (spécifiez-les au niveau de la correspondance d'utilisateur)
client_encoding (ceci est configuré automatiquement à partir de l'encodage du serveur local)
fallback_application_name (toujours configuré à postgres_fdw)
Seuls les superutilisateurs peuvent se connecter à un serveur distant sans authentification par mot de passe. Donc spécifiez toujours l'option password pour les correspondances d'utilisateur appartenant aux utilisateurs simples.
Pour information je vous colle la ligne de mon pg_hba.conf qui permet la connexion de n'importe user à n'importe quelle base sans mdp.
# IPv4 local connections:
host all all 127.0.0.1/32 trustSavez-vous contourner cette limitation?
Merci d'avance.
Ok merci pour tout.
J'attends le nouveau serveur pour upgrader la base, et j'attends avec impatience les vues dématérialisées de PostGIS.
Bonne soirée.
Ouf!
Je crois avoir réglé le problème à l'instant!
J'ai recréé ma table taxref, notamment à l'aide de ce tuto:
http://si.cenlr.org/postgresql_fdw_taxref
Et ça semble résoudre mes soucis.
Pour info le "\copy toto" semble fonctionner aussi (400 000 lignes et des poussières).
Je penche vers la table corrompue (je ne sais pas pourquoi ni à cause de quoi...).
Comme taxref est une table centrale (comprendre appelée par beaucoup d'autres), ça devait être le grain de sable qui grippait l'engrenage.
Existe-t-il une procédure pour savoir si une table contient des erreurs?
Je suis preneur de ce type d'information sur la maintenance globale du serveur.
Pour info notre version vieillissante:
PostgreSQL 9.1.15 on i686-pc-linux-gnu, compiled by gcc (Debian 4.7.2-5) 4.7.2, 32-bit
Merci pour ton aide en tous cas.
Euh joker pour le NOT IN! C'est un bout de code filé par un collègue qui touche plus que moi! (je suis plutôt débutant débutant/avancé).
J'obtiens le même résultat avec la requête suivante: SELECT cd_ref FROM inpn.taxref WHERE cd_ref <> cd_nom;
Alors le crash initial:
tentative 1 --> semble avoir marché
tentative 2 --> déconnecté du serveur
tentative 3 --> semble avoir marché
tentative 4 --> déconnecté du serveur
tentative 5 --> semble avoir marché
tentative 6 --> déconnecté du serveur
tentative 7 --> semble avoir marché
tentative 8 --> déconnecté du serveur
tentative 9 --> semble avoir marché
tentative 10 --> déconnecté du serveur
Je ne sais pas à partir de combien d'essai on peut dire que ça marche une fois sur deux mais ça semble être 50% fonctionnel et 50% problématique (même si j'attends un laps de temps variable entre chaque tentative).
Par contre côté contenu devrais-je avoir 452 103 lignes dans toto?
J'ai 452 103 dans la table taxref.
Voici la fin du fichier toto qui fait 33 116 lignes.
$tail /tmp/toto
Animalia Arthropoda Insecta Coleoptera Curculionidae Arthropodes Insectes 16409 188682 16409 ES Acallocrates denticollis (Germar, 1824) Acallocrates denticollis (Germar, 1824) <i>Acallocrates denticollis</i> (Germar, 1824) Acallocrates denticollis (Germar, 1824) 3 P http://inpn.mnhn.fr/espece/cd_nom/16409
Animalia Arthropoda Insecta Coleoptera Curculionidae Arthropodes Insectes 16410 188682 16409 ES Acalles denticollis Germar, 1824 Acalles denticollis Germar, 1824 <i>Acalles denticollis</i> Germar, 1824 Acallocrates denticollis (Germar, 1824) 3 P http://inpn.mnhn.fr/espece/cd_nom/16410
Animalia Arthropoda Insecta Coleoptera Curculionidae Arthropodes Insectes 16411 188682 16409 ES Acalles (Acallocrates) denticollis Acalles (Acallocrates) denticollis <i>Acalles </i>(<i>Acallocrates</i>)<i> denticollis</i> Acallocrates denticollis (Germar, 1824) 3 P http://inpn.mnhn.fr/espece/cd_nom/16411
Animalia Arthropoda Insecta Coleoptera Curculionidae Arthropodes Insectes 16412 188682 16412 ES Acallocrates minutesquamosus (Reiche, 1860) Acallocrates minutesquamosus (Reiche, 1860) <i>Acallocrates minutesquamosus</i> (Reiche, 1860) Acallocrates minutesquamosus (Reiche, 1860) 3 P http://inpn.mnhn.fr/espece/cd_nom/16412
Animalia Arthropoda Insecta Coleoptera Curculionidae Arthropodes Insectes 409293 188682 16412 ES Acalles discors Hoffmann, 1958 Acalles discors Hoffmann, 1958 <i>Acalles discors</i> Hoffmann, 1958 Acallocrates minutesquamosus (Reiche, 1860) 3 P http://inpn.mnhn.fr/espece/cd_nom/409293
Animalia Arthropoda Insecta Coleoptera Curculionidae Arthropodes Insectes 16413 188682 16412 ES Acalles minutesquamosus Reiche, 1862 Acalles minutesquamosus Reiche, 1862 <i>Acalles minutesquamosus</i> Reiche, 1862 Acallocrates minutesquamosus (Reiche, 1860) 3 P http://inpn.mnhn.fr/espece/cd_nom/16413
Animalia Arthropoda Insecta Coleoptera Curculionidae Arthropodes Insectes 188685 184685 188685 GN Acalyptus Acalyptus <i>Acalyptus</i> Acalyptus \N P
http://inpn.mnhn.fr/espece/cd_nom/188685
Animalia Arthropoda Insecta Coleoptera Curculionidae Arthropodes Insectes 15772 188685 15772 ES Acalyptus carpini (Fabricius, 1792) Acalyptus carpini (Fabricius, 1792) <i>Acalyptus carpini</i> (Fabricius, 1792) Acalyptus carpini (Fabricius, 1792) 3 P http://inpn.mnhn.fr/espece/cd_nom/15772
Animalia Arthropoda Insecta Coleoptera Curculionidae Arthropodes Insectes 409198 188685 15772 ES Acalyptus caucasicus Reitter, 1900 Acalyptus caucasicus Reitter, 1900 <i>Acalyptus caucasicus</i> Reitter, 1900 Acalyptus carpini (Fabricius, 1792) 3 P http://inpn.mnhn.fr/espece/cd_nom/409198
Animalia Arthropoda Insecta Coleoptera Curculionidae Arthropodes Insectes 409197 188685 15772 ES Acalyptus fuscipes Thomson, 1870 Acalyptus fuscipes Thomson, 1870 <i>Acalyptus fuscipes</i> Thomson, 1870 Acalyptus carpini (Fabricius, 1792) 3 P http://inpn.mnhn.fr/espece/cd_nom/409197Toutes mes versions de toto semblent identiques (même poids, même nombre de lignes, terminent tous par http://inpn.mnhn.fr/espece/cd_nom/409197 ).
C'est grave docteur?
Oui c'est un champ de la table taxref, de même que cd_ref.
Ce sont des champs en character varying pour les deux.
Ah pardon je n'avais pas compris.
Oui elle plante systématiquement.
cd_nom est un champ issu de TaxRef, le référentiel espèces fournit par le ministère de l'environnement (grosso modo!).
Là l'idée est de trouver les cd_ref qui ne sont pas dans les cd_nom.
En fait une espèce peut être saisie sous plusieurs noms car la taxonomie évolue.
Le crapaud croa peut s'appeler crapaud karaoua dans le référentiel suivant (la magie de la génétique! ).
Le référentiel évoluant plus vite que les naturalistes (imagine si tu devais réapprendre X noms d'espèces à chaque version ça deviendrait compliqué) il faut qu'on puisse saisir crapaud croa mais qu'en base le crapaud croa fasse bien référence au crapaud karoua.
D'où l'idée de cd_ref et cd_nom: cd_ref pour le code de référence saisi et cd_nom pour le code du nom valide de l'espèce pour le référentiel TaxRef.
Ainsi lorsque je t'envoie mes données naturalistes tu te trouveras avec uniquement des crapauds karoua même si j'ai saisi un crapaud croa. Puisque nous utilisons le même référentiel alors nous pouvons échanger sans trop bricoler (c'est une des utilités de TaxRef).
C'est peut-être un peu touffu mais j'espèce avoir été clair.
Si ça t'intéresse voici un lien vers TaxRef: http://inpn.mnhn.fr/programme/referenti … que-taxref
Les erreurs se produisent quasiment systématiquement, disons dans 60 à 80% des cas.
Si c'est une corruption de données comment puis-je identifier la donnée qui pose problème?
Dans le cas d'un problème serveur, il s'agirait d'un problème matériel type RAM ou disque dur montrant des signes de faiblesses ou tu penses à autre chose?
Merci en tous cas.
Bonjour à tous,
J'ai des déconnexions intempestives lors de requêtes simples (select sur 30 000 lignes par exemple) et sur des requêtes plus gourmandes.
Ce qui me donne côté client (psql) "erreur SYSCALL SSL : EOF détecté".
Exemple:
# SELECT cd_ref FROM inpn.taxref WHERE cd_ref NOT IN (cd_nom);erreur SYSCALL SSL : EOF détecté
La connexion au serveur a été perdue. Tentative de réinitialisation : Échec.
!>Côté serveur (Debian 7 + PostgreSQL 9.1):
Pour le log système (syslog):
Aug 24 10:18:17 Marmoratux kernel: [ 4328.062786] postgres[7245]: segfault at d0233c98 ip b722ee62 sp bf9da570 error 5 in postgres[b71cb000+553000]et pour le log PostgreSQL:
2015-08-24 10:18:17 CEST LOG: processus serveur (PID 7245) a ?t? arr?t? par le signal 11 : Segmentation fault
2015-08-24 10:18:17 CEST LOG: arr?t des autres processus serveur actifs
2015-08-24 10:18:17 CEST ATTENTION: arr?t de la connexion ? cause de l'arr?t brutal d'un autre processus serveur
2015-08-24 10:18:17 CEST D?TAIL: Le postmaster a command? ? ce processus serveur d'annuler la transaction
courante et de quitter car un autre processus serveur a quitt? anormalement
et qu'il existe probablement de la m?moire partag?e corrompue.
2015-08-24 10:18:17 CEST ASTUCE : Dans un moment, vous devriez ?tre capable de vous reconnecter ? la base de
donn?es et de relancer votre commande.
2015-08-24 10:18:17 CEST LOG: tous les processus serveur se sont arr?t?s, r?initialisation
2015-08-24 10:18:17 CEST LOG: le syst?me de bases de donn?es a ?t? interrompu ; dernier lancement connu ? 2015-08-24 10:17:28 CEST
2015-08-24 10:18:17 CEST LOG: le syst?me de bases de donn?es n'a pas ?t? arr?t? proprement ; restauration
automatique en cours
2015-08-24 10:18:17 CEST FATAL: le syst?me de bases de donn?es est en cours de restauration
2015-08-24 10:18:17 CEST FATAL: le syst?me de bases de donn?es est en cours de restauration
2015-08-24 10:18:17 CEST LOG: enregistrement de longueur nulle ? 9/CF5C73C
2015-08-24 10:18:17 CEST LOG: la r?-ex?cution n'est pas n?cessaire
2015-08-24 10:18:17 CEST LOG: le syst?me de bases de donn?es est pr?t pour accepter les connexions
2015-08-24 10:18:17 CEST LOG: lancement du processus autovacuumDe ce que j'en comprend le serveur PostgreSQL se prend les pieds dans le tapis mais je n'en comprend pas la cause.
Pourriez-vous m'éclairer de vos lanternes?
Merci d'avance.
PS: une migration est prévue sur une nouvelle machine bientôt suivi d'une mise à jour de postgresql, si au passage vous avez des conseils, liens ou informations diverses à me fournir je suis preneur. Car ce sera ma première fois!
Bonjour,
L'épluchage des logs m'indique que le soucis est survenu le 21 janvier (log postgresl).
Il est passé inaperçu jusqu'alors!
Mes logs systèmes ne remontent pas à cette date, du coup je suis coincé, impossible de trouver la cause exacte...
Je m'attelle à la restauration de la BDD ce jour.
Merci beaucoup pour toutes ces informations.
Bonsoir,
J'avoue ne pas bien saisir la notion de décalage entre" la définition de la table et la structure physique", de quoi s'agit-il?
Pour ma culture générale, existe t-il un moyen de faire correspondre la définition de la table et la structure physique d'une table?
Concernant la suppression des fichiers, ce n'est ni le fsck ni moi qui les ai supprimé.
Ils étaient absents avant que je lance le fsck, d'où l'erreur qui m'a fait prendre conscience qu'il y avait soucis.
En écrivant ces lignes, je me rend compte qu'il est possible que le soucis soit antérieur à mon problème de disque plein mais que je ne me sois pas rendu compte du problème...
Le problème viendrait alors d'ailleurs.
Affaire à suivre.
Merci du retour, et je vais m'atteler à restaurer une sauvegarde.
Bonne soirée.
Bonjour,
Désolé par avance du pavé, mais j'ai estimé que l'historique de mes recherches et actions seraient nécessaires à la résolution de mon problème.
Contexte:
Je suis un "grand débutant" sous postgreSQL (formation sur le tas, pas d'études d'informatique).
Nous utilisons un serveur debian 6.0.
Suite à une erreur dans un script de sauvegarde, j'ai rempli le disque du serveur hébergeant pSQL à 100%.
En me connectant au serveur via pgAdminIII je rencontrais une erreur du type (de mémoire, je n'ai pas noté l'intitulé exact):
accès impossible à la transaction #######
Accès impossible au fichier "pg_clog/XXXX"
Une fois le ménage réalisé (sans toucher aux fichiers de pSQL), j'ai redémarré et forcé un fsck ( = checkdisk pour les windowsiens), espérant supprimer les inodes pendants et résoudre le soucis.
Le fsck se déroule sans erreurs. Donc pas de souci de disque persistant.
Pour être sur j'ai lancé un test court smarmontools, passé avec brio.
J'en déduis que mon disque se porte bien et que l'erreur d'écriture des fichiers pg_clog/0FF# dépendait du remplissage du disque à 100%.
Après ces vérifications, je rencontrais toujours la même erreur.
En farfouillant un peu sur le net je suis tombé sur ce fil:
http://forums.postgresql.fr/viewtopic.php?id=359
J'ai alors créé les fichiers manquants grâce aux commandes suivantes:
dd bs=256K count=1 < /dev/zero >> /var/lib/pgsql/data/pg_clog/0FF1
dd bs=256K count=1 < /dev/zero >> /var/lib/pgsql/data/pg_clog/0FF5
dd bs=256K count=1 < /dev/zero >> /var/lib/pgsql/data/pg_clog/0FF7J'ai bien compris le message de gleu, en fin de discussion qui explique que cette solution de facilité. C'est un risque mesuré que j'ai souhaité prendre.
Je pensais mon problème réglé, mais j'ai eu besoin de réindexer la table pg_attritbute grâce à la commande:
REINDEX TABLE pg_attribute ;Je pensais le problème résolu, mais une nouvelle erreur est apparue, et c'est là que je sèche!
Point bloquant:
Je rencontre l'erreur suivante lors de l'ouverture d'une table via pgAdminIII:
"ERREUR: catalog is missing 2 attribute(s) for relid 2432122"
En cliquant sur valide, pgAdmin me liste l'intégralité des données de la table en question (saisie_observation).
J'ai 62031 données, lisibles, exploitables, etc.
Par contre le message d'erreur persiste.
En me connectant via psql je n'obtiens pas d'erreur. Ce qui me rend perplexe!
De plus, psql ne me renvoie pas le même résultat si j'utilise la commande
\dt saisie.* pour lister les tables de mon schéma, ou si j'utilise l'autocompletion.
Voici le résultat de l'autocomplétion:
SELECT count(*) FROM saisie.saisie_observation
saisie.saisie_observation saisie.saisie_observation_0 saisie.saisie_observation_1 saisie.saisie_observation_10 saisie.saisie_observation_11
saisie.saisie_observation_12 saisie.saisie_observation_13 saisie.saisie_observation_14 saisie.saisie_observation_15 saisie.saisie_observation_16
saisie.saisie_observation_18 saisie.saisie_observation_19 saisie.saisie_observation_2 saisie.saisie_observation_20 saisie.saisie_observation_23
saisie.saisie_observation_24 saisie.saisie_observation_25 saisie.saisie_observation_27 saisie.saisie_observation_3 saisie.saisie_observation_4
saisie.saisie_observation_40 saisie.saisie_observation_41 saisie.saisie_observation_42 saisie.saisie_observation_43 saisie.saisie_observation_44
saisie.saisie_observation_49 saisie.saisie_observation_5 saisie.saisie_observation_50 saisie.saisie_observation_52 saisie.saisie_observation_54
saisie.saisie_observation_57 saisie.saisie_observation_6 saisie.saisie_observation_61 saisie.saisie_observation_69 saisie.saisie_observation_7
saisie.saisie_observation_71 saisie.saisie_observation_72 saisie.saisie_observation_74 saisie.saisie_observation_77 saisie.saisie_observation_8
saisie.saisie_observation_83 saisie.saisie_observation_85 saisie.saisie_observation_87 saisie.saisie_observation_89 saisie.saisie_observation_9
saisie.saisie_observation_90 saisie.saisie_observation_91 saisie.saisie_observation_93 saisie.saisie_observation_95 saisie.saisie_observation_96
saisie.saisie_observation_id_obs_seq saisie.saisie_observation_59pgAdminIII ne vois pas l'intégralité des tables disponibles via l'autocomplétion de psql. Pourquoi?
Enfin si j'essaie de lancer à nouveau mon script de sauvegarde (pg_dumpall), j'ai les erreurs suivantes:
pg_dump: numérotation des colonnes invalide pour la table « saisie_observation_41 »
pg_dumpall : échec de pg_dump sur la base de données « eemyde », quitteJ'aimerais tirer tout ça au clair, supprimer cette erreur, comprendre son origine et pouvoir sauvegarder mes données comme avant!
Merci d'avance pour votre aide et vos idées, car tout ça est très flou pour moi.
PS: j'espère avoir posté au bon endroit, ce sont mes premiers pas sur ce forum.
Pages : 1