bonjour,

http://docs.postgresql.fr/9.3/runtime-c … gging.html

vous pouvez paramétrer postgresql avec log_statement = 'all' + log_connection = on (attention aux perfs !).
vous devez modifier également log_line_prefix pour avoir les infos que vous voulez (IP, date, base, utilisateur ...)
il est églament possible de logger au format csv : chapitre 18.8.4. "Utiliser les journaux au format CSV"

je confirme ce que dit pitpoule, mes standby en hot-streaming génèrent des WAL dans pg_xlog avec la même numérotation que le master et à la même vitesse (je ne parle pas de l'archivage du master vers le slave fait via archive_command).

lc_time est bien positionné à "fr_FR.UTF-8" dans postgresql.conf ?

pour moi il y a un pbs de conception, mais peut être que je ne comprends pas assez bien ton problème ...
J’aurai fait 3 tables :
- operation_reseau(operation_reseau_id(PK), ...)
- geo(geo_id(PK), type_geo_id(FK), operation_reseau_id(FK), ...)
- type_geo(type_geo_id(PK), num_geo, ...)

avec dans la colonne num_geo de la table type_geo les X des tables geo_X (1,2,3,4, ...)

C'est à mon avis bcp plus simple par la suite pour faire tes comptages.
Concernant tes contraintes (un operation_reseau_id pour un seul type_geo_id, mais avec N lignes possibles) -> vérification à faire par trigger BEFORE INSERT, UPDATE

tu peux déjà lancer cette requête qui va te sortir une liste de select à effectuer pour savoir si tu as des données à 1970-01-01 pour tes colonne de type TIMESTAMP WITHOUT TIME ZONE :

select 'select count(*) from ' || table_schema || '.' || table_name || ' where ' || column_name || '=''1970-01-01 00:00:00'';' from INFORMATION_SCHEMA.COLUMNS where data_type='timestamp without time zone';

le 1/ en utilisant une fonction automatique d’échappement suivant le langage utilisé pour peupler la base (quote en perl, pg_escape_bytea en php, ...).
"Le volume final est de ce fait augmenté d'un facteur 2 à 3" : d'après la doc, non : "Par exemple, une chaîne littérale passée au serveur comme E'\\001' devient \001 après être passée au travers de l'analyseur d'échappement de chaîne. Le \001 est envoyé à la fonction d'entrée de bytea, qui le convertit en un octet simple ayant une valeur décimale de 1", de plus ta donnée va être "Toasted" donc compressée.

bonjour,

pourquoi ne pas executer le script avec le user Postgres ?

Bonjour,

Cohérence : oui sans problème pour les deux.
pg_dump => backup d'une base d'un cluster
pg_dumpall => backup de toutes les bases d'un cluster

vous pouvez vous connecter en plsql et faire "show all;" sur chaque base pour voir si il y a une différence de configuration.
(le track_counts peut être modifié pour une base du cluster par exemple : alter database ??? set track_counts to 'off')

Bonjour,

J'utilise cette requête :

select
	current_database(),
	schemaname || '.' || relname as table,
	to_char(last_vacuum,'DD-MM-YYYY HH24:mi') as lastvacuum,
	to_char(last_autovacuum,'DD-MM-YYYY HH24:mi') as lastautovacuum,
	to_char(last_analyze,'DD-MM-YYYY HH24:mi') as lastanalyze,
	to_char(last_autoanalyze,'DD-MM-YYYY HH24:mi') as lastautoanalyze
from
	pg_stat_user_tables
order by
	2

Vous n'aurez pas l'historique du déclenchement de l'autovacuum mais au moins la date du dernier lancement par table

Bonjour,

quelle version de PostgreSql ?
quelle valeur pour shared_buffers (postgresql.conf) ?
quelle quantité de ram sur votre serveur ?
quelle est la taille de votre base ?
le serveur est-il dédié à PostgreSql ?
des ralentissements en lecture (select) ou en écriture (insert / update) ?