Vous n'êtes pas identifié(e).
Pages : 1
bonjour pitpoule,
Il y a une instance de work_mem utilisée par nœud de requête, donc, une requête avec un JOIN va utiliser 2 work_mem, un tri utilise un work_mem de plus, et ainsi de suite.
Le danger d'un work_mem trop élevé ce n'est pas seulement de faire du swap, c'est de se retrouver avec un oom-killer qui peux tuer le processus postmaster de postgres, ce qui peut entraîner des corruptions de données.
Pour s'en protéger, configurer
vm.overcommit_ratio
avec
vm.overcommit_memory = 2
définir vm.overcommit_ratio en suivant la formule suivante :
overcommit_ratio=target_ratio-(100/TOTAL RAM)*SWAP SIZE
target_ratio à 90 pour 90% est une valeur raisonnable.
Bonjour,
La ligne suivante :
host all all 192.168.1.45 md5
Devrait être écrite comme ca :
host all all 192.168.1.45/32 md5
Bonne journée !
merci pour cette réponse.
Pour reproduire le problème :
postgres@bobbynette:~/workdir$ cat 5435_toto_personne.sql
DROP TABLE IF EXISTS personne;
DROP DATABASE IF EXISTS toto;
DROP ROLE IF EXISTS toto_ro;
DROP ROLE IF EXISTS analysts;
DROP ROLE IF EXISTS dba;
DROP USER IF EXISTS tintin;
DROP USER IF EXISTS capitainehaddock;
DROP USER IF EXISTS milou;
CREATE ROLE analysts;
ALTER ROLE analysts WITH INHERIT;
CREATE ROLE dba;
ALTER ROLE dba WITH INHERIT;
CREATE ROLE toto_ro;
ALTER ROLE toto_ro WITH INHERIT;
CREATE USER tintin;
ALTER USER tintin WITH LOGIN INHERIT PASSWORD 'tintin' ;
ALTER GROUP analysts ADD USER tintin;
CREATE USER capitainehaddock;
ALTER USER capitainehaddock WITH LOGIN INHERIT PASSWORD 'capitainehaddock';
ALTER GROUP dba ADD USER capitainehaddock;
CREATE USER milou WITH LOGIN PASSWORD 'milou' ;
CREATE DATABASE toto;
ALTER DATABASE toto OWNER TO dba;
\c toto
CREATE TABLE personne (id_personne uuid, nom varchar, surnom varchar);
ALTER TABLE personne OWNER TO dba;
GRANT SELECT ON personne TO toto_ro;
GRANT toto_ro TO analysts;postgres@bobbynette:~/workdir$ cat 5434_pouet_ticket.sql
DROP TABLE IF EXISTS ticket;
DROP DATABASE IF EXISTS pouet;
DROP ROLE IF EXISTS pouet_ro;
DROP ROLE IF EXISTS analysts;
DROP ROLE IF EXISTS dba;
DROP USER IF EXISTS tintin;
DROP USER IF EXISTS capitainehaddock;
DROP USER IF EXISTS milou;
CREATE ROLE analysts;
ALTER ROLE analysts WITH INHERIT;
CREATE ROLE dba;
ALTER ROLE dba WITH INHERIT;
CREATE ROLE pouet_ro;
ALTER ROLE pouet_ro WITH INHERIT;
CREATE USER tintin;
ALTER USER tintin WITH LOGIN INHERIT PASSWORD 'tintin' ;
ALTER GROUP analysts ADD USER tintin;
CREATE USER capitainehaddock;
ALTER USER capitainehaddock WITH LOGIN INHERIT PASSWORD 'capitainehaddock';
ALTER GROUP dba ADD USER capitainehaddock;
CREATE USER milou WITH LOGIN;
CREATE DATABASE pouet;
ALTER DATABASE pouet OWNER TO dba;
\c pouet
CREATE TABLE ticket (id_ticket uuid, id_personne uuid, objet varchar);
ALTER TABLE ticket OWNER TO dba;
GRANT SELECT ON ticket TO pouet_ro;
GRANT pouet_ro TO analysts;postgres@bobbynette:~/workdir$ cat 5432_query_fdw.sql
-- # ========== 9.6 query/ticket_personne 5432
DROP FOREIGN TABLE IF EXISTS personne_site;
DROP FOREIGN TABLE IF EXISTS ticket_site;
DROP USER MAPPING IF EXISTS FOR tintin SERVER toto;
DROP USER MAPPING IF EXISTS FOR tintin SERVER pouet;
DROP USER MAPPING IF EXISTS FOR postgres SERVER toto;
DROP USER MAPPING IF EXISTS FOR postgres SERVER pouet;
DROP SERVER IF EXISTS pouet;
DROP SERVER IF EXISTS toto;
DROP DATABASE IF EXISTS query;
DROP ROLE IF EXISTS query_ro;
DROP ROLE IF EXISTS analysts;
DROP ROLE IF EXISTS dba;
DROP USER IF EXISTS tintin;
DROP USER IF EXISTS capitainehaddock;
DROP USER IF EXISTS milou;
CREATE ROLE analysts;
ALTER ROLE analysts WITH INHERIT;
CREATE ROLE dba;
ALTER ROLE dba WITH INHERIT;
CREATE USER tintin;
ALTER USER tintin WITH LOGIN INHERIT PASSWORD 'tintin' ;
ALTER GROUP analysts ADD USER tintin;
CREATE USER capitainehaddock;
ALTER USER capitainehaddock WITH LOGIN INHERIT PASSWORD 'capitainehaddock';
ALTER GROUP dba ADD USER capitainehaddock;
CREATE USER milou WITH LOGIN PASSWORD 'milou' ;
CREATE ROLE query_ro;
ALTER ROLE query_ro WITH INHERIT;
GRANT query_ro TO analysts;
CREATE DATABASE query;
ALTER DATABASE query OWNER TO dba;
\c query
-- # ====== FDW sur 9.6 query/ticket_personne 5432
CREATE SERVER pouet
FOREIGN DATA WRAPPER postgres_fdw
OPTIONS (service 'pouet');
CREATE FOREIGN TABLE ticket_site (id_ticket uuid, id_personne uuid, objet varchar)
SERVER pouet OPTIONS (schema_name 'public', table_name 'ticket');
GRANT SELECT ON ticket_site TO query_ro;
CREATE SERVER toto
FOREIGN DATA WRAPPER postgres_fdw
OPTIONS (service 'toto');
CREATE FOREIGN TABLE personne_site (id_personne uuid, nom varchar, surnom varchar)
SERVER toto OPTIONS (schema_name 'public', table_name 'personne');
GRANT SELECT ON personne_site TO query_ro;
CREATE user MAPPING FOR tintin SERVER toto OPTIONS ( USER 'tintin' , PASSWORD 'tintin');
CREATE user MAPPING FOR tintin SERVER pouet OPTIONS ( USER 'tintin' , PASSWORD 'tintin');
GRANT SELECT ON personne_site to query_ro ;
--query=# GRANT USAGE ON FOREIGN SERVER toto TO analysts ;
CREATE VIEW sites AS
SELECT pers.surnom as surnom, tic.id_ticket as ticket, tic.objet as objet
FROM ticket_site tic
JOIN personne_site pers ON pers.id_personne = tic.id_personne;
GRANT SELECT ON sites to query_ro;
-- CREATE USER MAPPING FOR postgres SERVER pouet OPTIONS ( user 'postgres', password 'pgsql');
-- CREATE USER MAPPING FOR postgres SERVER toto OPTIONS ( user 'postgres', password 'pgsql');
\c query tintin
SELECT 1 from sites;Bonjour,
Je crée une vue sur des tables distantes, mon utilisateur est habilité à lire les données des tables, mais n'accède pas à la vue si le propriétaire de la vue (postgres) n'a pas été mappé. Est ce normal ?
D'avance, merci pour vos retours.
Bonjour,
Avez vous regardé le contenu du fichier install-postgresql.log qui devrait se trouver dans un répertoire temporaire (/tmp sous linux ou %TEMP% sous windows) ?
Les informations qu'il contient pourraient vous renseigner quant à l'erreur que vous rencontrez.
Bonjour,
Il faut aussi que l'utilisateur PostgreSQL qui réalise la commande copy ai les droits suffisants sur la table dans laquelle les données sont importées, dans votre exemple BD.CP
Vous pouvez vérifier les droits et les privilèges avec les méta commandes \dp (describe privilege) et \du (describe users)
Je me répond à moi même :
pg_dump -p 5432 -Fp -s -n '"top.test"' -f save_hophop_sch_toptest.txt hophop
Pour que ça fonctionne.
PS : Ne pas mettre des caractères spéciaux dans les noms d'objets
Bonjour,
J'essaye d'importer/exporter des tables d'un schéma particulier, et de les importer en changeant certaines informations :
hophop=# set search_path = "$user", public, "top.test";
SET
hophop=# \dt+
List of relations
Schema | Name | Type | Owner | Size | Description
---------------+------------------------------+-------+----------+------------+-------------
top.test | --- | table | -- | 48 kB |
top.test | --- | table | -- | 280 kB |
top.test | --- | table | -- | 16 kB |
top.test | --- | table | -- | 4224 kB |Mais lorsque j'essaie de faire le dump de la structure de ce schéma il me retourne l'erreur suivante :
pg_dump -p 5432 -d hophop -Fp -s -n "top.test" -f save_hophop_sch_toptest.txt
pg_dump -p 5432 -d hophop -Fp -s -n top.test -f save_hophop_sch_toptest.txt
pg_dump -p 5432 -Fp -s -n "top.test" -f save_hophop_sch_toptest.txt hophop
pg_dump -p 5432 -Fp -s -n top.test -f save_hophop_sch_toptest.txt hophop
pg_dump -p 5432 -Fp -s -n hophop."top.test" -f save_hophop_sch_toptest.txt hophop
pg_dump: no matching schemas were foundUne idée de ce qui manque à ma commande pour qu'il puisse sauvegarder la structure du schéma en question ?
Une fois que j'aurais réussi à obtenir le sql de création de ce shéma, je souhaite modifier le nom du schéma en top_test et supprimer les majuscules dans les noms de colonnes.
Ya t'il des choses à mettre en place pour que mon import des données de l'ancienne structure vers la nouvelle fonctionne ?
D'avance merci de votre retour.
Question subsidiaire 
Si je définis mon fichier pg_hba.conf de cette manière :
# TYPE DATABASE USER ADDRESS METHOD
local all postgres peer
local all perette peer map=perettemapping
local all perette peer map=rootmapping# MAPNAME SYSTEM-USERNAME PG-USERNAME
rootmapping root perette
perettemapping sup peretteEt bien je ne peux pas utiliser la connexion avec root :
sup@bobbynette:~$ psql -p 5433 -U perette -d postgresfonctionne très bien tandis qu'avec root cela retourne une erreur.
root@bobbynette:~# psql -p 5433 -U perette -d postgres
psql: FATAL: Peer authentication failed for user "perette"C'est normal puisque pg_hba.conf est lu dans l'ordre et que les deux demandes vont matcher la première ligne et que peer map=perettemapping fonctionne seulement pour sup et pas pour root.
Ceci étant dit, du coup faut-il partir sur une seule association base/user par mapping d'utilisateur système ou il existe une manière de contourner ce truc ?
*Edit :
En rédigeant les fichier pg_ident.conf et pg_hba.conf de cette manière cela fonctionne :
# MAPNAME SYSTEM-USERNAME PG-USERNAME
perettemapping root perette
perettemapping sup perette# TYPE DATABASE USER ADDRESS METHOD
local all postgres peer
local all perette peer map=perettemappingMerci, c'est très clair et ça marche.
Je note le warning sur le fait que la connexion avec root est une mauvaise idée (mais pourquoi? puisqu'on peut dans tous les cas faire un su - postgres avec root ?)
@pluche !
Bonjour,
Les deux fichiers stipulés en objet contiennent les informations suivantes :
pg_ident.conf :
# MAPNAME SYSTEM-USERNAME PG-USERNAME
mappingroot root postgrespg_hba.conf :
# TYPE DATABASE USER ADDRESS METHOD
local all postgres peer map=mappingroot
local all all peerLa configuration a été rechargée plusieurs fois (select pg_reload_conf() ; )
Lorsque, connectée avec l'utilisateur root, je tente de me connecter à PostgreSQL, j'obtiens l'erreur suivante :
root@bobbynette:~# psql -p 5433
psql: FATAL: role "root" does not existJe pensais que justement, avec l'association ident, root allait être considéré comme s'il était postgres, et donc que je n'avais pas à créer utilisateur et db dans l'instance concernée?
D'avance merci.
Au top cette réponse, merci.
Bonjour,
Je lance la commande suivante :
bobby=# VACUUM tutu.pouet;Et lorsque je vérifie j'obtiens :
bobby=# select * from pg_stat_user_tables where relname = 'pouet';
relid | schemaname | relname | seq_scan | seq_tup_read | idx_scan | idx_tup_fetch | n_tup_ins | n_tup_upd | n_tup_del | last_vacuum | last_autovacuum | last_analyze | last_autoanalyze
---------+------------+------------------+----------+--------------+----------+---------------+-----------+-----------+-----------+-------------+-----------------+--------------+------------------
8906637 | tutu | pouet | 0 | 0 | | | 0 | 0 | 0 | | | |
(1 row)La version de mon instance PostgreSQL est :
PostgreSQL 8.2.15 (Greenplum Database 4.3.6.1 build 2)Comportement identique avec ANALYZE.
Bonne fin de journée et bon week-end
Pages : 1