Vous n'êtes pas identifié(e).
Pages : 1
C'est résolu.
En fait dans le paramétrage du serveur sous pgAdmin le label "maintenance database" de l'onglet "connexion" m'avait un peu embrouillé, c'est tout simplement le nom de la base à laquelle on veut se connecter !
Merci
Oui tu as raison gleu, j'aurais dû avoir ce réflexe, réponse : FATAL: aucune entrée dans pg_hba.conf pour l'hôte « 10.252.235.18 », utilisateur « reader »,
Donc il faut que je revois ma façon de coder l'adresse IP ...
Merci !
Bonjour à tous,
J'ai alimenté une base en version 10 sous Windows.
Je suis en télétravail, le serveur avec la base est dans l'établissement de notre entreprise.
Je souhaite donner une accès en lecture seule à cette base (pas via internet) , l'entreprise est grande, beaucoup de gens sont en télétravail et donc les adresses IP de tous ces gens risquent être de formes variées.
J'ai donc créé la ligne suivante pour le rôle reader : host kenobi reader 0.0.0.0/0 md5
Depuis mon micro chez moi, j'arrive à me connecter avec psql et à requêter sur la base.
Par contre ça ne passe pas depuis pgAdmin 4 (avec la même machine), quand je valide après avoir saisi le mot de passe, il me réaffiche la boîte de dialogue pour saisir le mot de passe et pas moyen d'en sortir.
Je précise que je me suis déjà connecter depuis ce micro avec pgAdmin 4 en utilisateur postgres et method trust.
Y a t'il quelqu'un qui a une idée ?
Bon j'ai finalement trouvé.
C'est simplement les administrateurs de la machine qui avaient mis un quota à 500 Mo par personne ...
Merci à rjuju et gleu, vos interventions n'ont pas été inutiles car vous m'avez tous les deux appris des trucs qui me seront utiles.
Cordialement, Didier
Merci tes indications et conseils rjuju.
J'ai fait générer le script de création de la base j'obtiens cela :
CREATE DATABASE kenobi
WITH
OWNER = postgres
ENCODING = 'UTF8'
LC_COLLATE = 'French_France.1252'
LC_CTYPE = 'French_France.1252'
TABLESPACE = kenobi_space
CONNECTION LIMIT = -1;
Pour le tablespace :
CREATE TABLESPACE kenobi_space
OWNER postgres
LOCATION 'I:\ArchiveKenobi\data_kenobi';
ALTER TABLESPACE kenobi_space
OWNER TO postgres;
Si je fais un dir dans C:\Program Files\PostgreSQL\10\data\pg_tblspc, j'ai l'affichage suivant :
Répertoire de C:\Program Files\PostgreSQL\10\data\pg_tblspc
06/08/2020 10:39 <JONCTION> 16394 [\??\I:\ArchiveKenobi\data_kenobi]
16/10/2020 15:01 <JONCTION> 18418 [\??\I:\ArchiveSiec\data_siec]
Si je vais voir sur I:
I:\ArchiveKenobi\data_kenobi>dir
Le volume dans le lecteur I s'appelle Data
Le numéro de série du volume est 06B7-39B4
Répertoire de I:\ArchiveKenobi\data_kenobi
06/08/2020 10:39 <REP> .
06/08/2020 10:39 <REP> .
25/09/2020 14:21 <REP> PG_10_201707211
0 fichier(s) 0 octets
3 Rép(s) 171 799 588 864 octets libres
Dans PG_10_201707211 j'ai :
Répertoire de I:\ArchiveKenobi\data_kenobi\PG_10_201707211
25/09/2020 14:21 <REP> .
25/09/2020 14:21 <REP> ..
26/10/2020 07:04 <REP> 16396
25/10/2020 17:32 <REP> pgsql_tmp
0 fichier(s) 0 octets
4 Rép(s) 171 799 588 864 octets libres
Sous windows en demandant les propriétés de 16396 j'obtiens un volume de 529 Mo
Sous PgAdmin 4, quand je sélectionne kenobi_space et que je prends l'onglet "Dependants", il liste le contenu du tablespace, il y a la base kenobi, les tables, indexes et vues.
Ma base est bien là.
Pour la table sur laquelle le vaccum full a planté, pgAdmin indique :
Table size : 58 MB
Indexes size : 13 MB
Ca n'a vraiment rien d'énorme !
Pgsql_tmp est vide.
J'ai activé le paramètre : log_temp_files = -1
Cela n'a rien résolu ...
J'ai paramétré "temp_buffers = 50MB", mais la façon dont est utilisée ce para n'est pas 100% claire pour moi, est ce suffisant ?
Bonjour à tous,
J'ai installé récemment un PostgreSql 10 (je débute sur ce SGBD) sur un windows 2008 Server (fallait prendre ce qui était dispo).
Le but étant d'assurer pendant quelques années l'accès à des données issues d'une application qui va être arrêtée.
Après avoir chargé 1 an de données, j'ai voulu faire des requêtes de contrôle, ça plante sur l'une d'elle.
La requête qui pose problème fait appel à des agrégats, sur 2 mois elle passe, mais sur 1 an ça plante :
ERROR: ERREUR: n'a pas pu écrire le fichier temporaire de la jointure hâchée : No space left on device CONTEXT: processus parallèle
SQL state: 53100
J'ai créé un tablespace que j'ai défini comme étant celui par défaut pour ma base de données, il est défini sur un lecteur qui a 160Go de libre
Si je demande sa taille dans le gestionnaire de fichier, il m'indique 529Mo.
Je n'ai rien spécifié pour faire créer les objets temporaires dans un espace spécifique, donc si j'ai bien compris il crée les trucs temporaires sur le tablespace de la base, lequel a 160Go de libre !
En examinant plus loin, je me rend compte qu'il me manque un index et que ma requête entraîne un table scan pour une jointure.
Donc j'essaye de créer l'index manquant, mais là nouvelle erreur :
ERROR: ERREUR: n'a pas pu étendre le fichier « pg_tblspc/16394/PG_10_201707211/16396/18536 » : No space left on device HINT: Vérifiez l'espace disque disponible.
SQL state: 53100
J'ai essayé la requête suivante :
select datname, temp_files, temp_bytes
from pg_stat_database
Elle donne :
"postgres" 0 0
"template1" 0 0
"template0" 0 0
"kenobi" 486 466064825
"siec" 0 0
Si j'interprète cela correctement, le tablespace de ma base contient 486 fichiers temporaires pour plus de 400 Mo.
Même après redémarrage de PostgreSql j'ai toujours le même résultat.
Les 529 Mo indiqués par windows ne pourraient pas contenir les données chargées + 400 Mo de fichier temporaires, il y a déjà une incohérence à ce niveau, ou alors les fichiers temporaires son ailleurs ?
J'ai essayé de modifier un paramètre, j'ai enlevé la mise en commentaire : temp_file_limit = -1
Ca n'a rien changé au problème.
Sous pgAdmin 4 j'ai essayé de lancer un vacuum ordinaire (aucune des options cochées : full, freeze, analyse), il passe en 15s
Si je tente un full ça plante en 1s, après avoir pu passer des petites tables de référence, il plante sur la première table importante à laquelle il s'attaque :
INFO: exécution du VACUUM sur "public.t_clients"
ERREUR: n'a pas pu étendre le fichier "pg_tblspc/16394/PG_10_201707211/16396/18558" : No space left on device
HINT: Vérifiez l'espace disque disponible
Par contre le répertoire indiqué est sur C: C:\Program Files\PostgreSQL\10\data\pg_tblspc
Sur C: il y a 27 Go de libre.
Y a-t-il des paramètres à contrôler ?, que me conseiller vous ?
Pages : 1
