Vous n'êtes pas identifié(e).

Pages : 1

#1 Re : Général » Taille mémoire maximale d'un process backend » 11/01/2018 17:57:20

superette

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.

#2 Re : Général » accéder à distant à une base de donnée » 14/09/2017 09:13:22

superette

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 !

#3 Re : Sécurité » Problème de droits sur vue crée sur des tables distantes » 10/09/2017 16:56:18

superette

merci pour cette réponse.

#4 Re : Sécurité » Problème de droits sur vue crée sur des tables distantes » 09/09/2017 13:36:48

superette

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;

#5 Sécurité » Problème de droits sur vue crée sur des tables distantes » 09/09/2017 13:27:29

superette
Réponses : 3

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.

#6 Re : Installation » Installation plusieurs Version de Postgresql sur une même VM » 07/07/2017 13:57:40

superette

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.

#7 Re : Général » Permission denied » 30/06/2017 15:04:16

superette

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)

#8 Re : Général » Problème de schéma » 23/06/2017 21:00:47

superette

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

#9 Général » Problème de schéma » 23/06/2017 18:19:15

superette
Réponses : 2

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 found

Une 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.

#10 Re : Général » pg_ident.conf et pg_hba.conf » 22/05/2017 16:08:58

superette

Question subsidiaire smile 

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                           perette

Et bien je ne peux pas utiliser la connexion  avec root : 

sup@bobbynette:~$ psql -p 5433 -U perette -d postgres

fonctionne 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=perettemapping

#11 Re : Général » pg_ident.conf et pg_hba.conf » 22/05/2017 13:29:18

superette

Merci, 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 !

#12 Général » pg_ident.conf et pg_hba.conf » 22/05/2017 12:01:30

superette
Réponses : 4

Bonjour,

Les deux fichiers stipulés en objet contiennent les informations suivantes :

pg_ident.conf :

# MAPNAME       SYSTEM-USERNAME PG-USERNAME
mappingroot     root            postgres

pg_hba.conf :

# TYPE  DATABASE        USER            ADDRESS                 METHOD
local   all             postgres                                peer map=mappingroot
local   all             all                                     peer

La 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 exist

Je 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.

#13 Re : Général » Vacuum exécuté et non tracé dans pg_stat_all_tables/pg_stat_use » 05/05/2017 17:52:27

superette

Au top cette réponse, merci.

smile

#14 Général » Vacuum exécuté et non tracé dans pg_stat_all_tables/pg_stat_use » 05/05/2017 17:04:37

superette
Réponses : 2

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 smile

Pages : 1

Pied de page des forums

Propulsé par FluxBB