Bonjour,
j'ai précédemment fait une demande pour un problème avec la lib pltcl, j'ai refait mon install avec apt-get plutôt qu'une compilation manuelle, tout va bien.

J'ai quelques erreurs qui subsistent (ou avertissements).

psql:/opt/infocentre.dat:556: ATTENTION:  la fonction en entrée du type chkpass_in ne doit pas être volatile
psql:/opt/infocentre.dat:556: ATTENTION:  la fonction en entrée du type chkpass_out ne doit pas être volatile
psql:/opt/infocentre.dat:658: ATTENTION:  la fonction en entrée du type gbtreekey16_in ne doit pas être volatile
psql:/opt/infocentre.dat:658: ATTENTION:  la fonction en entrée du type gbtreekey16_out ne doit pas être volatile
psql:/opt/infocentre.dat:702: ATTENTION:  la fonction en entrée du type gbtreekey32_in ne doit pas être volatile
psql:/opt/infocentre.dat:702: ATTENTION:  la fonction en entrée du type gbtreekey32_out ne doit pas être volatile
psql:/opt/infocentre.dat:746: ATTENTION:  la fonction en entrée du type gbtreekey4_in ne doit pas être volatile
psql:/opt/infocentre.dat:746: ATTENTION:  la fonction en entrée du type gbtreekey4_out ne doit pas être volatile
psql:/opt/infocentre.dat:790: ATTENTION:  la fonction en entrée du type gbtreekey8_in ne doit pas être volatile
psql:/opt/infocentre.dat:790: ATTENTION:  la fonction en entrée du type gbtreekey8_out ne doit pas être volatile
psql:/opt/infocentre.dat:834: ATTENTION:  la fonction en entrée du type gbtreekey_var_in ne doit pas être volatile
psql:/opt/infocentre.dat:834: ATTENTION:  la fonction en entrée du type gbtreekey_var_out ne doit pas être volatile
psql:/opt/infocentre.dat:878: ATTENTION:  la fonction en entrée du type ghstore_in ne doit pas être volatile
psql:/opt/infocentre.dat:878: ATTENTION:  la fonction en entrée du type ghstore_out ne doit pas être volatile
psql:/opt/infocentre.dat:922: ATTENTION:  la fonction en entrée du type gtrgm_in ne doit pas être volatile
psql:/opt/infocentre.dat:922: ATTENTION:  la fonction en entrée du type gtrgm_out ne doit pas être volatile
psql:/opt/infocentre.dat:996: ATTENTION:  la fonction en entrée du type hstore_in ne doit pas être volatile
psql:/opt/infocentre.dat:996: ATTENTION:  la fonction en entrée du type hstore_out ne doit pas être volatile
psql:/opt/infocentre.dat:1093: ATTENTION:  la fonction en entrée du type lquery_in ne doit pas être volatile
psql:/opt/infocentre.dat:1093: ATTENTION:  la fonction en entrée du type lquery_out ne doit pas être volatile
psql:/opt/infocentre.dat:1137: ATTENTION:  la fonction en entrée du type ltree_in ne doit pas être volatile
psql:/opt/infocentre.dat:1137: ATTENTION:  la fonction en entrée du type ltree_out ne doit pas être volatile
psql:/opt/infocentre.dat:1181: ATTENTION:  la fonction en entrée du type ltree_gist_in ne doit pas être volatile
psql:/opt/infocentre.dat:1181: ATTENTION:  la fonction en entrée du type ltree_gist_out ne doit pas être volatile
psql:/opt/infocentre.dat:1225: ATTENTION:  la fonction en entrée du type ltxtq_in ne doit pas être volatile
psql:/opt/infocentre.dat:1225: ATTENTION:  la fonction en entrée du type ltxtq_out ne doit pas être volatile
psql:/opt/infocentre.dat:25109: ERREUR:  erreur de syntaxe sur ou près de « => »
LIGNE 1 : CREATE OPERATOR => (
                          ^
psql:/opt/infocentre.dat:25112: ERREUR:  erreur de syntaxe sur ou près de « => »
LIGNE 1 : ALTER OPERATOR public.=> (text, text) OWNER TO postgres;

Je vous donne le code de la fonction create:

CREATE OPERATOR => (
    PROCEDURE = tconvert,
    LEFTARG = text,
    RIGHTARG = text
);

Une idée? et que penser des alertes au dessus concernant le "volatile"?
Le code par exemple pour ltxtq_out:

CREATE FUNCTION ltxtq_out(ltxtquery) RETURNS cstring
    LANGUAGE c STRICT
    AS '$libdir/ltree', 'ltxtq_out';


ALTER FUNCTION public.ltxtq_out(ltxtquery) OWNER TO postgres;

Merci par avance.

Olivier

Bonjour,

J'ai installé postgres9.6 pour faire quelques tests sur cette version (installation via code source sous debian car pas de packets dispo).
J'ai ces erreurs lors d'un psql -f avec un de mes dumps :

psql:/opt/infocentre.dat:345: ERROR:  could not open extension control file "/usr/local/pgsql/share/extension/pltcl.control": Aucun fichier ou dossier de ce type
psql:/opt/infocentre.dat:352: ERROR:  extension "pltcl" does not exist
...

Or si je liste les extensions dispo dans le repertoire contrib de mes sources j'ai:

adminpack     btree_gin   contrib-global.mk  dict_xsyn	    hstore	     intarray  ltree_plpython  passwordcheck	pg_prewarm	    pgstattuple    README   sslinfo	   test_decoding    unaccent
auth_delay    btree_gist  cube		     earthdistance  hstore_plperl    isn       Makefile        pg_buffercache	pgrowlocks	    pg_trgm	   seg	    start-scripts  tsearch2	    uuid-ossp
auto_explain  chkpass	  dblink	     file_fdw	    hstore_plpython  lo        oid2name        pgcrypto		pg_standby	    pg_visibility  sepgsql  tablefunc	   tsm_system_rows  vacuumlo
bloom	      citext	  dict_int	     fuzzystrmatch  intagg	     ltree     pageinspect     pg_freespacemap	pg_stat_statements  postgres_fdw   spi	    tcn		   tsm_system_time  xml2

Pas de pltcl à l'horizon...

Quelle extension dois-je utiliser svp?

Merci par avance,

Olivier Bouiron

Bonjour,
Notre base de prod étant en 9.3, nous planifions une mise à jour en fin d'année vers la 9.6 si la roadmap est tenue...
On a donc préparé un serveur de tests en 9.6: les conditions sont similaires au niveau du postgresql.conf, les deux serveurs sont sous debian (mais versions de debian différentes).
Par contre grosse différence: la 9.6 tourne sur des disques 7k tours en raid 5 alors que la 9.3 est sur du ssd.

J’exécute une même requête:

select * from premio_presc_v2 a inner join dsi_presc_cycle b on a.id=b.idpres inner join premio_presc_jour_produit c on c.idcycle=b.id where a.nip=200903667 and b.cycle=2 limit 10;

Sous 9.6 ça prends 13ms pour afficher le resultat dans pg_admin
Sous 9.3 ça prends 22ms pour afficher le resultat dans pg_admin

Le explain analyze en 9.6 donne:

 Limit  (cost=1.14..18.45 rows=5 width=1439) (actual time=0.059..0.085 rows=10 loops=1)
   ->  Nested Loop  (cost=1.14..18.45 rows=5 width=1439) (actual time=0.057..0.083 rows=10 loops=1)
         ->  Nested Loop  (cost=0.71..13.53 rows=1 width=986) (actual time=0.042..0.042 rows=1 loops=1)
               ->  Index Scan using idx_presc_premio_nip on premio_presc_v2 a  (cost=0.29..5.41 rows=2 width=577) (actual time=0.017..0.017 rows=1 loops=1)
                     Index Cond: (nip = 200903667)
               ->  Index Scan using idx_dsi_cycle on dsi_presc_cycle b  (cost=0.42..4.05 rows=1 width=409) (actual time=0.019..0.019 rows=1 loops=1)
                     Index Cond: (idpres = a.id)
                     Filter: (cycle = 2)
                     Rows Removed by Filter: 2
         ->  Index Scan using idx_presc_jour_premio1 on premio_presc_jour_produit c  (cost=0.43..4.58 rows=34 width=453) (actual time=0.011..0.022 rows=10 loops=1)
               Index Cond: (idcycle = b.id)
 Planning time: 1.645 ms
 Execution time: 0.480 ms

et le explain analyze en 9.3 donne:

Limit  (cost=1.14..13.53 rows=5 width=1447) (actual time=0.040..0.055 rows=10 loops=1)
   ->  Nested Loop  (cost=1.14..13.53 rows=5 width=1447) (actual time=0.040..0.054 rows=10 loops=1)
         ->  Nested Loop  (cost=0.71..9.79 rows=1 width=994) (actual time=0.027..0.027 rows=1 loops=1)
               ->  Index Scan using idx_presc_premio_nip on premio_presc_v2 a  (cost=0.29..3.91 rows=2 width=577) (actual time=0.012..0.012 rows=1 loops=1)
                     Index Cond: (nip = 200903667)
               ->  Index Scan using idx_dsi_cycle on dsi_presc_cycle b  (cost=0.42..2.93 rows=1 width=417) (actual time=0.013..0.013 rows=1 loops=1)
                     Index Cond: (idpres = a.id)
                     Filter: (cycle = 2)
                     Rows Removed by Filter: 2
         ->  Index Scan using idx_presc_jour_premio1 on premio_presc_jour_produit c  (cost=0.43..3.48 rows=26 width=453) (actual time=0.010..0.020 rows=10 loops=1)
               Index Cond: (idcycle = b.id)
 Total runtime: 0.178 ms

Sauriez-vous pourquoi pgadmin prends plus de temps à afficher le résultat depuis la 9.3 alors que normalement, les requêtes devraient être plus rapide sur la 9.3 (cf explain), ce qui d'ailleurs se vérifie par exemple via une connexion jdbc: la requête en 9.3 prends 3ms, tandis qu'en 9.6, c'est 4ms.

Question annexe: est-on censé gagner sérieusement en perf en passant de la 9.3 à la 9.6?

Bonjour,

Une question: si je crée une table :
CREATE TABLE test.table1
(
  c1 double precision,
  c2 bigint,
  c3 double precision
)WITH (  OIDS=FALSE );
ALTER TABLE test.table1  OWNER TO postgres;

Et que j'insere 18 400 000 de lignes en mettant tout à null, ma table fait : 989MB.
Je pensais que si les valeurs étaient nulles on ne perdait pas de place...
Plus étrange, si j'enleve les colonnes c2 et c3, la taille passe à 495MB, soit la moitié, alors que j'ai retiré deux colonnes sur trois.

Enfin, j'ai tenté des calculs, si il y avait des infos dans ces colonnes au lieu de null:
18 400 000 * ( 8 bits + 8 bits + 8 bits, soit 24 bits ) = 421Mo de datas

Au lieu des 421Mo j'ai 989Mo et en plus c'est tout null...

Quelqu'un saurait m'expliquer svp?

Merci!

Olivier B.

Bonjour,

Je connecte des clients à postgres depuis une appli java via JDBC.
Une connection par client, la connection reste toujours active.

Cependant par moment je ne vois pas certains clients dans pg_stat_activity puis ils réapparaissent.

Il me semblait que cette vue permettait d'avoir la liste des backend avec leur pid.
Est-il possible qu'un client garde une connection acteve via jdbc mais n'apparaisse pas dans pg_stat_activity? (par exemple s'il ne fait pas de requetes pendant quelques secondes)?

De plus imaginons que j'ai des coupures réseaux, quelle durée faut il pour que le client n'apparaisse plus dans pg_stat_activity? c'est immédiat des que la personne n'est plus sur le reseau ou il y a un temps défini?

Merci pour votre aide.

Olivier Bouiron

Bonjour, je fais face régulièrement à des TopMemoryContext sur mon serveur postgres , obligé à chaque fois de faire un restart pour que tout rentre dans l'ordre.

J'ai beau chercher, je ne comprends pas le pourquoi du problème.

C'est aléatoire... par contre à ma grande surprise hier j'ai changé le shared_buffers à 7GB au lieu des 4GB habituels, et ce matin, 3 plantages similaires, cette fois-ci le restart ne corrigeait le problème que quelques minutes puis ça recommençait...  jusqu’à ce que je repasse à 4GB, et là c'est revenu à la normale.

Pourtant free -m montrait aucun swap et plusieurs GB encore free.

Je précise que à 4GB de sharred j'ai environ un plantage par semaine de ce type.

Ma config:
Postgresql 9.3.6 64bits sur debian wheezy virtualisé sous vmware, dédié à postgres.
Ram : 16GB
Taille de la base: 35GB

config postgres:
shared_buffers = 4GB
work_mem=4MB
maintenance_WM=256MB
max_stack_depth=4MB

J'ai analysé les logs du jour du plantage: pas de pics de requêtes, ou de connexions au moment des plantages.

Que veut dire topmemorycontext? le passage à 7GB de shared_buffers peut-il réellement avoir une incidence négative??

Voici une des traces d'erreur:

Date: 2015-06-26 08:53:01
Detail: Failed on request of size 4240.
Statement: select a.log_user_cre, a.oid, a.provenance, a.type_entree_planification, a.type_prevision_sortie,a.nip,a.depart,a.fin,if('dsi_planning_salle_attente_secteur'='dsi_planning_salle_attente_secteur' and ((select count(z.*)>0 from dsi_planning_lit z where z.nip = a.nip and (z.depart >= a.fin or (z.depart<a.fin and z.fin>0 and z.fin >a.fin) ) and cast(gc2pg(z.depart) AS date) = cast(gc2pg(a.fin) as date))or (a.etat = 0 and (select count(z.*)>0 from dsi_planning_lit z where z.nip = a.nip and (z.depart < a.depart ) and cast(gc2pg(z.fin) AS date) = cast(gc2pg(a.depart) as date)))),3,a.etat) AS etat,a.commentaire,a.motif,a.demande,a.motif2,a.motif3, a.degre_autonomie, a.idsecteur, frenchtime(a.date_creation_planif) AS fdDateCreation, a.liste_permission, a.destination, a.chambre_particuliere ,d.id AS idOriginePlanning ,if((select count(z.*)=0 from vue_premio_presc_detail_toppe z where z.nip = a.nip and z.dateadm = cast(gc2pg(a.depart) as date) and z.dateko is null) and (cast(e.depart as date)!=cast(gc2pg(a.depart) as date) or (d.date_rdz is not null and e.id is null and (select count(z.*)=0 from agenda_agenda z where z.idress= d.id_ressource and z.nip = a.nip and z.depart = d.date_rdz))),-1,if((select count(z.*)=0 from vue_premio_presc_detail_toppe z where z.nip = a.nip and z.dateadm = cast(gc2pg(a.depart) as date) and z.dateko is null) ,null,e.etat)) AS etatRdz from dsi_planning_salle_attente_secteur a left join dsi_agenda_planning_lit d ON d.nip = a.nip and d.id=(select min(f.id) from dsi_agenda_planning_lit f where f.nip = a.nip and if(1435355999999 is null, true, f.depart< 1435355999999) and (f.depart > 1435269600000 or f.depart is null )  ) left join agenda_agenda e on e.id = d.id where if(1435355999999 is null, true, a.depart<= 1435355999999) and (a.fin > 1435269600000 or a.fin is null ) and a.idsecteur in (2) order by a.nip,a.depart
TopMemoryContext: 221952 total in 17 blocks; 18952 free (56 chunks); 203000 used
  TopTransactionContext: 8192 total in 1 blocks; 7392 free (0 chunks); 800 used
  Type information cache: 24240 total in 2 blocks; 3744 free (0 chunks); 20496 used
  Operator lookup cache: 24576 total in 2 blocks; 11888 free (5 chunks); 12688 used
  TableSpace cache: 8192 total in 1 blocks; 3216 free (0 chunks); 4976 used
  MessageContext: 16544 total in 2 blocks; 2328 free (3 chunks); 14216 used
  Operator class cache: 8192 total in 1 blocks; 1680 free (0 chunks); 6512 used
  smgr relation table: 24576 total in 2 blocks; 5696 free (4 chunks); 18880 used
  TransactionAbortContext: 32768 total in 1 blocks; 32736 free (0 chunks); 32 used
  Portal hash: 8192 total in 1 blocks; 1680 free (0 chunks); 6512 used
  PortalMemory: 8192 total in 1 blocks; 7888 free (0 chunks); 304 used
    PortalHeapMemory: 1024 total in 1 blocks; 848 free (0 chunks); 176 used
  Relcache by OID: 24576 total in 2 blocks; 11792 free (3 chunks); 12784 used
  CacheMemoryContext: 1342128 total in 21 blocks; 4256 free (3 chunks); 1337872 used
    CachedPlanSource: 3072 total in 2 blocks; 352 free (0 chunks); 2720 used
      unnamed prepared statement: 24576 total in 2 blocks; 15904 free (2 chunks); 8672 used
    idx_planning_salleattente_1: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
    index_dsi_planning_secteur_idsecteur_depart_fin: 3072 total in 2 blocks; 1736 free (2 chunks); 1336 used
    idx_planning_secteur_1: 3072 total in 2 blocks; 1736 free (2 chunks); 1336 used
    idx_planning_secteur_0: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
    index_idx_planning_chambre_0_idchambre_deb_fin: 3072 total in 2 blocks; 1736 free (2 chunks); 1336 used
    index_dsi_planning_chambre_depart_fin: 1024 total in 1 blocks; 16 free (0 chunks); 1008 used
    idx_planning_chambre_0: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
    index_dsi_code_lit_id: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
    index_dsi_code_chambre_id: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
    index_dsi_code_secteur_id: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
    pk_bugzilla_utilisateur: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
    index_adm_param_type: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
    index_adm_param_param: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
    EventTriggerCache: 8192 total in 1 blocks; 8160 free (2 chunks); 32 used
      Event Trigger Cache: 8192 total in 1 blocks; 3744 free (0 chunks); 4448 used
    dextr_date_extraction_pkey: 1024 total in 1 blocks; 16 free (0 chunks); 1008 used
    idx_quicklinks: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
    idx_util_work_mem: 1024 total in 1 blocks; 200 free (0 chunks); 824 used
    index_prog_connexion_logs_users_connexion: 1024 total in 1 blocks; 16 free (0 chunks); 1008 used
    index_prog_connexion_pid: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
    prog_connexion_pkey: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
    index_prog_utilisateur_preference_cle_login: 1024 total in 1 blocks; 16 free (0 chunks); 1008 used
    index_prog_group_utilisateur_utilisateur: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
    index_prog_appli_group_groupe: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
    pk_prog_appli_group_groupe: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
    pg_toast_2619_index: 1024 total in 1 blocks; 16 free (0 chunks); 1008 used
    index_prog_utilisateur_code: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
    prog_utilisateur_password_index_for_ldap: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
    index_prog_utilisateur_id: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
    unik_prog_util_login: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
    unik_prog_util_code: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
    pk_prog_utilisateur_initiales: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
    pk_pro_util_id: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
    index_adm_code_entite_code: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
    pkeycode: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
    pg_index_indrelid_index: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
    pg_attrdef_adrelid_adnum_index: 1024 total in 1 blocks; 16 free (0 chunks); 1008 used
    pg_db_role_setting_databaseid_rol_index: 1024 total in 1 blocks; 16 free (0 chunks); 1008 used
    pg_opclass_am_name_nsp_index: 3072 total in 2 blocks; 1736 free (2 chunks); 1336 used
    pg_foreign_data_wrapper_name_index: 1024 total in 1 blocks; 200 free (0 chunks); 824 used
    pg_enum_oid_index: 1024 total in 1 blocks; 200 free (0 chunks); 824 used
    pg_class_relname_nsp_index: 1024 total in 1 blocks; 16 free (0 chunks); 1008 used
    pg_foreign_server_oid_index: 1024 total in 1 blocks; 200 free (0 chunks); 824 used
    pg_statistic_relid_att_inh_index: 3072 total in 2 blocks; 1736 free (2 chunks); 1336 used
    pg_cast_source_target_index: 1024 total in 1 blocks; 16 free (0 chunks); 1008 used
    pg_language_name_index: 1024 total in 1 blocks; 200 free (0 chunks); 824 used
    pg_collation_oid_index: 1024 total in 1 blocks; 200 free (0 chunks); 824 used
    pg_amop_fam_strat_index: 3072 total in 2 blocks; 1736 free (2 chunks); 1336 used
    pg_index_indexrelid_index: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
    pg_ts_template_tmplname_index: 1024 total in 1 blocks; 64 free (0 chunks); 960 used
    pg_ts_config_map_index: 3072 total in 2 blocks; 1784 free (2 chunks); 1288 used
    pg_opclass_oid_index: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
    pg_foreign_data_wrapper_oid_index: 1024 total in 1 blocks; 200 free (0 chunks); 824 used
    pg_event_trigger_evtname_index: 1024 total in 1 blocks; 200 free (0 chunks); 824 used
    pg_ts_dict_oid_index: 1024 total in 1 blocks; 200 free (0 chunks); 824 used
    pg_event_trigger_oid_index: 1024 total in 1 blocks; 200 free (0 chunks); 824 used
    pg_conversion_default_index: 3072 total in 2 blocks; 1784 free (2 chunks); 1288 used
    pg_operator_oprname_l_r_n_index: 3072 total in 2 blocks; 1736 free (2 chunks); 1336 used
    pg_trigger_tgrelid_tgname_index: 1024 total in 1 blocks; 16 free (0 chunks); 1008 used
    pg_enum_typid_label_index: 1024 total in 1 blocks; 64 free (0 chunks); 960 used
    pg_ts_config_oid_index: 1024 total in 1 blocks; 200 free (0 chunks); 824 used
    pg_user_mapping_oid_index: 1024 total in 1 blocks; 200 free (0 chunks); 824 used
    pg_opfamily_am_name_nsp_index: 3072 total in 2 blocks; 1784 free (2 chunks); 1288 used
    pg_foreign_table_relid_index: 1024 total in 1 blocks; 200 free (0 chunks); 824 used
    pg_type_oid_index: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
    pg_aggregate_fnoid_index: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
    pg_constraint_oid_index: 1024 total in 1 blocks; 200 free (0 chunks); 824 used
    pg_rewrite_rel_rulename_index: 1024 total in 1 blocks; 64 free (0 chunks); 960 used
    pg_ts_parser_prsname_index: 1024 total in 1 blocks; 64 free (0 chunks); 960 used
    pg_ts_config_cfgname_index: 1024 total in 1 blocks; 64 free (0 chunks); 960 used
    pg_ts_parser_oid_index: 1024 total in 1 blocks; 200 free (0 chunks); 824 used
    pg_operator_oid_index: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
    pg_namespace_nspname_index: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
    pg_ts_template_oid_index: 1024 total in 1 blocks; 200 free (0 chunks); 824 used
    pg_amop_opr_fam_index: 3072 total in 2 blocks; 1736 free (2 chunks); 1336 used
    pg_default_acl_role_nsp_obj_index: 3072 total in 2 blocks; 1784 free (2 chunks); 1288 used
    pg_collation_name_enc_nsp_index: 3072 total in 2 blocks; 1784 free (2 chunks); 1288 used
    pg_range_rngtypid_index: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
    pg_ts_dict_dictname_index: 1024 total in 1 blocks; 64 free (0 chunks); 960 used
    pg_type_typname_nsp_index: 1024 total in 1 blocks; 16 free (0 chunks); 1008 used
    pg_opfamily_oid_index: 1024 total in 1 blocks; 200 free (0 chunks); 824 used
    pg_class_oid_index: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
    pg_proc_proname_args_nsp_index: 3072 total in 2 blocks; 1736 free (2 chunks); 1336 used
    pg_attribute_relid_attnum_index: 1024 total in 1 blocks; 16 free (0 chunks); 1008 used
    pg_proc_oid_index: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
    pg_language_oid_index: 1024 total in 1 blocks; 200 free (0 chunks); 824 used
    pg_namespace_oid_index: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
    pg_amproc_fam_proc_index: 3072 total in 2 blocks; 1736 free (2 chunks); 1336 used
    pg_foreign_server_name_index: 1024 total in 1 blocks; 200 free (0 chunks); 824 used
    pg_attribute_relid_attnam_index: 1024 total in 1 blocks; 64 free (0 chunks); 960 used
    pg_conversion_oid_index: 1024 total in 1 blocks; 200 free (0 chunks); 824 used
    pg_user_mapping_user_server_index: 1024 total in 1 blocks; 64 free (0 chunks); 960 used
    pg_conversion_name_nsp_index: 1024 total in 1 blocks; 64 free (0 chunks); 960 used
    pg_authid_oid_index: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
    pg_auth_members_member_role_index: 1024 total in 1 blocks; 16 free (0 chunks); 1008 used
    pg_tablespace_oid_index: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
    pg_database_datname_index: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
    pg_auth_members_role_member_index: 1024 total in 1 blocks; 64 free (0 chunks); 960 used
    pg_database_oid_index: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
    pg_authid_rolname_index: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
  MdSmgr: 8192 total in 1 blocks; 6176 free (0 chunks); 2016 used
  ident parser context: 0 total in 0 blocks; 0 free (0 chunks); 0 used
  hba parser context: 15360 total in 4 blocks; 6544 free (2 chunks); 8816 used
  LOCALLOCK hash: 24576 total in 2 blocks; 13920 free (4 chunks); 10656 used
  Timezones: 83472 total in 2 blocks; 3744 free (0 chunks); 79728 used
  ErrorContext: 8192 total in 1 blocks; 8160 free (0 chunks); 32 used
Database: infocentre User: amedic Remote:

J'étais à la journée workshop dalibo la semaine derniere, j'ai tenté d'analyser les logs avec pg_badger mais rien ne me choque... quand à pgcluu il n'était pas lancé à ce moment là.

Auriez-vous une idée?

Cordialement

Olivier Bouiron