Bonjour,

Sauf erreur de ma part initdb initialise la locale et l'encodage de jeu de caractères par défaut du cluster en se basant sur template 1

Ma question est la suivante :

Est ce que les valeurs des paramètre  LC_COLLATE et LC_CTYPE du template 1 seront toujours les mêmes lors d'un initdb ?
ou bien peux  ton trouver des valeurs différentes en fonctions de l'installation (rds,sqlcloud,distribution...) ?

Merci

Bonjour,

J'aurai voulu savoir si un slave peut impacter les performances de son Master ?
Mon master étant surchargé depuis plusieurs jour je viens tout juste de me rendre compte qu'une requête SELECT était en cours sur le slave depuis plusieurs jours
Mais une fois la requête cancel sur le slave, la Master reste toujours chargé.

Pour infos :
archive_command = 'AWS_REGION=eu-west-1 wal-e --s3-prefix s3://bucket --aws-instance-profile wal-push %p'
wal_level =hot_standby
archive_mode = on
hot_standby = on

Merci

Bonjour,

Je viens de remarquer un reset de stats sur ma base postgres (à 01:00) et ma base en production (à 20h14),

J'aurai voulu comprendre le pourquoi mes 2 bases ont été reset !  Pour information il y a eu intervention sur la base "ma_base_prod_db" avec un pg_terminate_backend à 20h14  ( heure du reset )

SELECT datname, stats_reset from pg_stat_database;
  datname  |          stats_reset         
-----------+-------------------------------
ma_base_prod_db | 2019-05-29 20:14:55
template0 |
postgres  | 2019-05-30 01:00:01
template1 |
(4 rows)

Merci à vous

Bonjour ,

Je dois faire un vacuum full sur la table pg_largeobject , après un premier test il a mit plus de 8h.

J'aimerai savoir quels peuvent être les paramètres de conf postgresql à modifier pour accélérer le temps de ce vacuum !

Contexte :
Juste le vacuum full de pg_largeobject  tournera sur la base,  la table contient 500 millions de live tuples et plus d'un milliard de dead rows.
maintenance_work_mem='2GB'

Machine :
CPU Intel(R) Xeon(R) CPU E5-2686 v4 @ 2.30GHz (16 threads) -- 64 Go RAM

Merci

Bonjour,

J'ai testé la suppression de 35k rows sur une table "table_lob" , résultat 3h30 !!! c'est vraiment trop long et j'aimerai comprendre pourquoi 

Le contexte :

- Sur la table "table_lob" il y a un trigger qui fait :  AFTER DELETE ON table_lob FOR EACH ROW EXECUTE PROCEDURE delete_lo()
- Un autovaccum (prevent wraparound) en cours sur la table pg_largeobjet

Je pense que le trigger y est pour quelques chose , et j'aimerai savoir si l'autovacuum sur pg_largeobject a aussi des conséquences sur le temps du Delete ?
Je suis aussi ouvert à toute proposition pour améliorer mon temps de suppression.

Merci d'avance

Bonjour,

Voici ma situation :

J'ai la possibilité de faire une interruption de service de plusieurs heures chez un client ,
J'aimerai donc on profiter pour faire un VACUUM FULL sur la table pg_largeobjet : 4 To  dont 700 gigas de données ....

J'ai actuellement un autovacuum: VACUUM pg_catalog.pg_largeobject (to prevent wraparound) qui tourne depuis plusieurs mois ..

Première question : Y'a t-il un risque à cancel l'autovacuum: VACUUM pg_catalog.pg_largeobject (to prevent wraparound) ? afin que je puisse lancer mon VACUUMFULL

Deuxième question : Comment faire pour que l'autovacuum  (to prevent wraparound) ne s'active pas entre le moment ou je vais le cancel et le moment ou je lancerai mon VACUUMFULL (j'ai cru comprendre que meme avec autovacuum off il s'activait)

En espérant avoir été suffisamment clair .

Merci

Bonjour,

J'aurai une petite question concernant la commande psql -c :

Voici un script utilisé sur ma machine locale version 9.6 :
for row in $schema_table; do
  psql -At $database -c "set statement_timeout = 20000;" -c "ANALYZE $row; -- anal_all_tables.sh cron" || true
done

Résultat :
SET
ANALYZE
SET
ANALYZE
SET
ANALYZE
.......

Et ce même script sur une machine "prod" version 9.5 renvoie :

ANALYZE
ANALYZE
ANALYZE
ANALYZE
ANALYZE
.....

Donc sur ma machine local (9.6) le set statement_timeout = 20000 est bien prit en compte ,
alors que sur la machine "prod" il n'est pas prit en compte.

J'aimerai comprendre le cause de se problème , est ce que la version postgresql joue un role ? ou bien est un changement de conf qui influe psql sur la machine prod !

Merci !!!!

Bonjour ,

J'ai actuellement une table pg_largeobject qui fait 3.5 Teraoctet dont 2.5 Teraoctect de bloat et 1 Tera de livetuples !

Petite question technique :

Aujourd'hui je pense qu'un vacuumfull sur cette table mettrait plusieurs jours, mais j'aimerai savoir si le fait de supprimer une grande partie des livetuples diminurait le temps de ce vacuumfull ???

Merci

Bonjour,

Voici ma situation :

J'ai une table "toto" qui reçoit des select H24 , (Access share)
J'aimerai pouvoir faire sur cette même table  :   ALTER TABLE toto add column test1 varchar(10);    (Access exclusif)

Mes problèmes sont que Access share et Access exclusive sont en conflit et je ne peux donc pas effectuer mon ALTER TABLE tant que le SELECT n'a pas commit et de plus mon ALTER TABLE (qui est en attente) bloque les SELECT suivants.

Existe - il aujourd'hui une astuce pour "forcer" cet ALTER TABLE malgré le conflit des locks ou bien dois je trouver le moment idéal ( nuit ) pour effectuer ce DDL.

En espérant avoir été claire ..

Merci

Bonjour tout le monde ,

Je viens d'installer PgBadger sur une VM Ubuntu et mon maître d'apprentissage me demande de générer un fichier html afin d'optimiser des requêtes à l'avenir .

Mon problème est que le fichier log que j'ai reçu de ça part est en CSV et que la commande de base ne passe pas du fait de son format ,
Ça me retourne donc une erreur "Can't locate Text/CSV_XS.pm ......."

Je pense que la solution se trouve ici : https://github.com/dalibo/pgbadger/tree/master/tools
Mais je ne vois pas comment faire pour installer ce "tools" .

Merci d'avance et bonne journée .

Ps : désolé si je ne suis pas dans la bonne rubrique je viens tout juste de m'inscrire .