Bonsoir à tous.
J'avais oublié de mettre à jour ce post.
Effectivement, l'augmentation du à l'échappement  ne se limite qu'à la RAM (durant la manip de la donnée avec un programme C/ecpg).
J'ai ré-importé une table de 60Go d'Oracle vers Postgresql et le volume est quasi-identique entre les 2 serveurs.
Merci arthurr.

Ok.
Alors disons que dans le cas où l'utilité est avérée et si vous avez été confronté à une telle configuration, quelle a été pour vous la solution la plus satisfaisante parmi celles que j'ai listées.
Je vous remercie par avance.

Bonjour Guillaume.
Ca explique effectivement mon soucis.
Merci à tous.

Bonjour à tous et merci pour vos réponses.

Rjuju, ni le \d, \d+, \dt, \dt+ ne me donnent le nom du tablespace sur ma config (9.2.4) ?
Effectivement la fonction pg_relation_filepath() peut aider mais il va falloir que je l'encapsule car on n'obtient pas le nom du tablespace à la première lecture.

bde=# select  pg_relation_filepath('img.tab1');
             pg_relation_filepath
----------------------------------------------
pg_tblspc/17917/PG_9.2_201204301/17915/28553

bash-4.1$ ll /base/data/pg_tblspc
total 0
lrwxrwxrwx 1 postgres postgres 16 Jul 10 09:33 17917 -> /base/ts_1

SQLPro, merci pour la doc. Très intéressante.
Juste une petite remarque, certaines requêtes ne passent plus en 9.2 à cause de la colonne pg_tablespace.spclocation qui n'existe plus.

David.

Bonjour.
Quand vous dites "il ne faut pas", il s'agit juste d'éviter ce problème de comptabilité n'est ce pas ? Car je ne vois pas plus de risque à être dans cette configuration qu'avec une configuration sans TS.
D'ailleurs dans notre cas, il s'agit d'un choix de départ pour nous permettre, si jamais le volume de la base venait à s'accroitre au delà de nos estimations, de déplacer ceci sur un autre FS (que nous n'avons pas aujourd'hui).
David

Bonjour Guillaume.

Oui, la rotation est peut-être faite sur le même fichier mais le RAZ de ce fichier non alors que "log_truncate_on_rotation=on".
C'est ce à quoi je m'attendais à avoir comme comportement c.a.d. un même fichier mais écrasé par la rotation dès que la taille excède celle précisée par le paramètre log_rotation_size.

Testé aujourd'hui avec la 9.2.1 avec les paramètres suivants:
log_destination = 'stderr'           
logging_collector = on                 
log_directory = 'pg_log'               
log_filename = 'postgresql-%a.log' 
log_truncate_on_rotation = on         
log_rotation_age = 0                 
log_rotation_size = 10kb             

[postgres@david60:/data/dav921/data/pg_log]$ ll
total 64
-rw------- 1 postgres postgres 63655  7 déc.  10:37 postgresql-Fri.log   <--  63k
-rw------- 1 postgres postgres     0 27 nov.  00:00 postgresql-Tue.log
-rw------- 1 postgres postgres     0 28 nov.  00:00 postgresql-Wed.log

NB : j'ai le même comportement avec la 9.0.

Voila un bon exercice pour se débloquer le cerveau en ce début de semaine !
Une première idée....
Cdlt

select * from debit;
        date         | debit
---------------------+-------
2012-01-01 00:00:00 |   1.2
2012-01-02 00:00:00 |   8.4
2012-01-03 00:00:00 |   8.2
2012-01-04 00:00:00 |   1.0
2012-01-05 00:00:00 |   1.0
2012-01-06 00:00:00 |   1.0
2012-01-07 00:00:00 |   1.0
2012-01-08 00:00:00 |   1.4
2012-01-09 00:00:00 |  51.4
2012-01-10 00:00:00 |   0.4
2012-01-11 00:00:00 |   0.4
2012-01-12 00:00:00 |   0.4
2012-01-13 00:00:00 |   0.0
2012-01-14 00:00:00 |   0.0
(14 lignes)

select min(D1) date_debut, debit, count(*)+1 from
(select d1.date D1, d2.date D2, d1.debit Debit  from debit d1, debit d2
where d2.date = d1.date + interval '1 day' ::interval and d1.debit=d2.debit and d1.debit >= 0) R1
group by debit;
         date_debut| debit | ?column?
---------------------+-------+----------
2012-01-13 00:00:00 |   0.0 |        2
2012-01-10 00:00:00 |   0.4 |        3
2012-01-04 00:00:00 |   1.0 |        4

Guillaume, je n'ai pas compris ce que vous vouliez dire: "ce qu'il serait intéressant, c'est de savoir quel type de verrou où les sessions qui sont en "idle in transaction".
Je n'ai qu'une seule session "IDLE in rtansaction"
Ceci.

postgres=# select
     pg_stat_activity.datname,pg_class.relname,pg_locks.transactionid, pg_locks.mode, pg_locks.granted,
     pg_stat_activity.usename,substr(pg_stat_activity.current_query,1,30), pg_stat_activity.query_start,
     age(now(),pg_stat_activity.query_start) as "age", pg_stat_activity.procpid
   from pg_stat_activity,pg_locks full
     join pg_class on (pg_locks.relation = pg_class.oid)
   where pg_locks.pid=pg_stat_activity.procpid  and substr(pg_stat_activity.current_query,1,30) like '%IDLE%' order by query_start;
datname | relname | transactionid |     mode      | granted | usename |        substr         |          query_start          |       age       | procpid
---------+---------+---------------+---------------+---------+---------+-----------------------+-------------------------------+-----------------+---------
base1  |         |               | ExclusiveLock | t       | base1| <IDLE> in transaction | 2012-11-07 10:16:56.637027+00 | 00:01:44.220869 |   23932
(1 ligne)

Non pas de différence notée.

Autre info, le phénomène ne se produit que sur une seule des 2 bases créées sur le même cluster !?!
Les colonnes  n_tup_ins, n_tup_del, etc... restent à '0' alors qu'il y a a peu près 200.000 insert par jour dans la 1ère table.
Le nombre de lignes n'est pas correct non plus (cf ci-dessous).

base1=# select relname,seq_tup_read,n_tup_ins,n_tup_upd,n_tup_del,n_tup_hot_upd,n_live_tup,n_dead_tup,last_autovacuum,last_autoanalyze from pg_stat_all_tables where relname like '%tres%';

       relname        | seq_tup_read | n_tup_ins | n_tup_upd | n_tup_del | n_tup_hot_upd | n_live_tup | n_dead_tup |        last_autovacuum        |       last_autoanalyze
----------------------+--------------+-----------+-----------+-----------+---------------+------------+------------+-------------------------------+-------------------------------
tres1                   |     35937175 |    350087 |         0 |         0 |             0 |     395251 |          0 | 2012-10-24 08:08:15.264593+00 |
tres2                   |     22404351 |     59210 |         0 |     59349 |             0 |        233 |          0 | 2012-10-23 12:06:29.676185+00 | 2012-10-23 12:06:29.676185+00
tres3                   |  52762897978 |  26307205 |         0 |  26275065 |             0 |      36634 |          0 | 2012-10-23 12:14:46.377767+00 | 2012-10-23 12:14:46.377767+00

base1=# select count(*) from tres1;
count
--------
444375
(1 ligne)

Les stats du cluster indiquent bien de l'activité sur CHACUNE des bases et une requête à intervalle régulier souligne bien cette activité (tup_inserted, tup_updated ):
postgres=# select * from pg_stat_database ;
datid |  datname  | numbackends | xact_commit | xact_rollback |  blks_read   |   blks_hit   | tup_returned | tup_fetched | tup_inserted | tup_updated | tup_deleted
-------+-----------+-------------+-------------+---------------+--------------+--------------+--------------+-------------+--------------+-------------+-------------
....
...
16390 | base1   |          12 |   100205231 |          1688 | 654814538597 | 114046341945 | 638065108162 |  1279110249 |    352344801 |    13979769 |   351056792
16391 | base2    |           3 |     6252807 |          4604 |     52260426 |    877573728 |   9650447251 |   247968875 |     52513721 |     1544963 |    51502840

L'autovacuum positionnée à 10%:

base1=# \d+ tres1
                        Table « public.tres1 »
   Colonne    |            Type             | Modificateurs | Stockage | Description
--------------+-----------------------------+---------------+----------+-------------
...
...
Index :
    "pk_tres1" PRIMARY KEY, btree (id)
    "i_tres1_1" btree (coldd, dateo)
Contient des OID: non
Options: autovacuum_vacuum_scale_factor=0.1

Je n'ai pas d'info dans la log sur le déclenchement de l'autovacuum. Il y-a-t-il de l'info ailleurs (table système) ?
Comme indiqué, pour cette table j'ai abaissé le niveau à 10%. Je l'avais calibré pour environ 3 à 4 passages par jour.
Cdlt

Bonjour à tous.
J'ai eu le même message d'erreur la semaine dernière en redémarrant une base de preprod (PostGresql 9.x + PostGIS 2.0).
Le LD_LIBRARY_PATH par défaut avait été surchargé depuis l'install (! - /etc/profile) et la libproj.so accédée n'était plus celle de la version 4.7 mais une vieille version (libproj.so.0.6.6, livrée avec le système) sous /usr/lib64 qui n'embarquait pas fonction citée ici (pj_get_spheroid_defn).
J'ai donc repositionné la variable et tout a redémarré sans problème.
Cordialement