Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
#601 Re : Général » [RESOLU] Forcer le tri dans le tablespace temp » 23/01/2013 10:54:48
Bonjour,
Dans le postgresql.conf : temp_tablespaces = 'temp' (TABLESPACE temp LOCATION '/P0K2YY51_2/tmp';)
Au niveau de la base de données : TABLESPACE = choregie_db_data (/P0K2YY51_1/data/choregie_db/choregie_db_data)
Au niveau du user : SET default_tablespace = 'user_data'; (/P0K2YY51_1/data/choregie_db/user_data)
Au niveau de la session, je ne sais pas.
Donc à mon sens il n'y a qu'un seul tablespace temporaire définit dans nos cluster : "temp"
select * from pg_tablespace :
"pg_default";10;""
"pg_global";10;""
"temp";10;"/P0K2YY51_2/tmp"
"choregie_db_data";10;"/P0K2YY51_1/data/choregie_db/choregie_db_data"
"choregie_db_idx";10;"/P0K2YY51_2/idx/choregie_db/choregie_db_idx"
"sdbd_choregie_db_data";16388;"/P0K2YY51_1/data/choregie_db/sdbd_data"
"sdbd_choregie_db_idx";16388;"/P0K2YY51_2/idx/choregie_db/sdbd_idx"
"clog_data";17942;"/P0K2YY51_1/data/choregie_db/clog_data"
"clog_idx";17942;"/P0K2YY51_2/idx/choregie_db/clog_idx"
"clog_trv";17942;"/P0K2YY51_2/trv/choregie_db/clog_trv"
"mcod_data";28107;"/P0K2YY51_1/data/choregie_db/mcod_data"
"mcod_idx";28107;"/P0K2YY51_2/idx/choregie_db/mcod_idx"
"mcod_trv";28107;"/P0K2YY51_2/trv/choregie_db/mcod_trv"
#602 Re : Général » [RESOLU] Forcer le tri dans le tablespace temp » 23/01/2013 10:26:23
Quelqu'un a une idée ? parce que ce genre de comportement sur les fichiers temporaires fait exploser nos files system...
#603 Re : Général » ORDER BY sur colonne de type text » 23/01/2013 10:24:27
Le problème vient de la collation (fr_FR.utf8) : dans ce cas postgresql ignore les espaces dans les tris. Ce n'est pas terrible comme façon de trier... est-ce normal ?
Et puis choisir une autre collation pourrait avoir des effets de bords sur le tri des mots accentués par exemple...
#604 Re : Général » [RESOLU] Forcer le tri dans le tablespace temp » 17/01/2013 10:08:03
Effectivement la requête de la fonction qui génère des fichiers temporaires serait la suivante :
INSERT INTO COT_ADHESIONCOUVERTURE(ideah, idecvt)
SELECT map1.idesq, map2.idesq
FROM ADHESION_TRV a
INNER JOIN COUVERTURES_TRV cv
ON cv.ideah = a.ideah
INNER JOIN MAPPING_TRV map1
ON map1.cle = 'ideah'
AND map1.idecar = a.ideah
INNER JOIN MAPPING_TRV map2
ON map2.cle = 'idecvt'
AND map2.idecar = cv.idecvt
WHERE a.top = 'I';
Mais ce que l'on ne comprend pas c'est pourquoi les temp sont générés dans /P0K2YY51_1/data/choregie_db/choregie_db_data/PG_9.1_201105231/pgsql_tmp au lieu de /P0K2YY51_2/tmp/PG_9.1_201105231/pgsql_tmp ?
#605 Général » [RESOLU] Forcer le tri dans le tablespace temp » 16/01/2013 17:23:03
- ruizsebastien
- Réponses : 17
Bonjour,
La documentation postgresql nous dit ceci :
"Les fichiers temporaires (pour des opérations comme le tri de plus de données que ce que la mémoire peut contenir) sont créés à l'intérieur de PGDATA/base/pgsql_tmp, ou dans un sous-répertoire pgsql_tmp du répertoire du tablespace si un tablespace autre que pg_default est indiqué pour eux. Le nom du fichier temporaire est de la forme pgsql_tmpPPP.NNN, où PPP est le PID du serveur propriétaire et NNN distingue les différents fichiers temporaires de ce serveur. "
Chez nous les opérations de tri (order by, groupby, etc...) sont bien faite dans le tablespace temporaire défini par "temp_tablespaces" dans pg_settings (qui est pour nous : /P0K2YY51_2/tmp/PG_9.1_201105231/pgsql_tmp).
Mais nous voyons dans nos logs (pg_log) que certaines opérations comme de gros insert produisent des fichiers temporaires dans un file system qui contient les data (/P0K2YY51_1/data/choregie_db/choregie_db_data/PG_9.1_201105231/pgsql_tmp).
Est-ce normal et comment pouvons nous forcer tous ces fichiers temporaires à aller dans "temp_tablespaces" ?
Un exemple :
INSERT INTO COT_COUVERTURE
SELECT trv.idedos, trv.idessc, trv.noctr FROM DOSSIER_TRV trv
Insert on cot_couverture (cost=0.00..50039.04 rows=1748352 width=24)
-> Seq Scan on dossier_trv trv (cost=0.00..50039.04 rows=1748352 width=24)
2013-01-16 11:40:45 CET [14593]: [16-1] user=mcod_b,db=choregie_dbLOG: temporary file: path "pg_tblspc/16385/PG_9.1_201105231/pgsql_tmp/pgsql_tmp14593.4", size 44960818
2013-01-16 11:40:45 CET [14593]: [17-1] user=mcod_b,db=choregie_dbSTATEMENT: SELECT P_EnrDonneesCalculCot_Personne(185,'MCOT,CC,011P,0,2')
2013-01-16 11:40:47 CET [14593]: [18-1] user=mcod_b,db=choregie_dbLOG: temporary file: path "pg_tblspc/16385/PG_9.1_201105231/pgsql_tmp/pgsql_tmp14593.5", size 154718280
On voit ici que le temporary file est générer dans le tablespace 16385 qui correspond chez nous à /P0K2YY51_1/data/choregie_db/choregie_db_data/PG_9.1_201105231/pgsql_tmp...
#606 Re : Général » ORDER BY sur colonne de type text » 14/01/2013 16:50:09
A priori, ça devrait être bon comme ça :
(prise en compte des espaces et des apostrophes dans le tri en ne prenant en compte que le texte à partir de " - ")
select title FROM AssetEntry
WHERE (visible = true) AND ( AssetEntry.classTypeId = 11577)
AND (AssetEntry.groupId = 11070 OR AssetEntry.groupId = 11070 )
AND (AssetEntry.classNameId = 10108)
ORDER BY substring(translate(title, ' ''', '11') from length(split_part(title,' - ',1))+1) ASC;
#607 Re : Général » ORDER BY sur colonne de type text » 14/01/2013 15:53:57
Avec cette requête j’obtiens presque le bon tri :
select title FROM test.AssetEntry
WHERE (visible = true) AND ( AssetEntry.classTypeId = 11577)
AND (AssetEntry.groupId = 11070 OR AssetEntry.groupId = 11070 )
AND (AssetEntry.classNameId = 10108)
ORDER BY substring(title from 126) ASC; -- j’ignore les 126 premiers caractères.
Et pourtant, non.... on voit bien que les sections ne sont pas bien triées :
"<?xml version='1.0' encoding='UTF-8'?><root available-locales="fr_FR" default-locale="fr_FR"><Title language-id="fr_FR">SD93 - Section de Seine Saint-Denis à Bondy</Title></root>"
"<?xml version='1.0' encoding='UTF-8'?><root available-locales="fr_FR" default-locale="fr_FR"><Title language-id="fr_FR">SD05 - Section des Hautes-Alpes à Gap</Title></root>"
"<?xml version='1.0' encoding='UTF-8'?><root available-locales="fr_FR" default-locale="fr_FR"><Title language-id="fr_FR">SD65 - Section des Hautes-Pyrénées à Tarbes</Title></root>"
"<?xml version='1.0' encoding='UTF-8'?><root available-locales="fr_FR" default-locale="fr_FR"><Title language-id="fr_FR">SD92 - Section des Hauts de Seine à Boulogne-Billancourt</Title></root>"
"<?xml version='1.0' encoding='UTF-8'?><root available-locales="fr_FR" default-locale="fr_FR"><Title language-id="fr_FR">SD40 - Section des Landes à Mont-de-Marsan</Title></root>"
"<?xml version='1.0' encoding='UTF-8'?><root available-locales="fr_FR" default-locale="fr_FR"><Title language-id="fr_FR">SD64 - Section des Pyrénées-Atlantiques à Biarritz</Title></root>"
"<?xml version='1.0' encoding='UTF-8'?><root available-locales="fr_FR" default-locale="fr_FR"><Title language-id="fr_FR">SD66 - Section des Pyrénées-Orientales à Perpignan</Title></root>"
"<?xml version='1.0' encoding='UTF-8'?><root available-locales="fr_FR" default-locale="fr_FR"><Title language-id="fr_FR">SD88 - Section des Vosges à Épinal</Title></root>"
"<?xml version='1.0' encoding='UTF-8'?><root available-locales="fr_FR" default-locale="fr_FR"><Title language-id="fr_FR">SD78 - Section des Yvelines à Montigny le Bretonneux</Title></root>"
"<?xml version='1.0' encoding='UTF-8'?><root available-locales="fr_FR" default-locale="fr_FR"><Title language-id="fr_FR">SD84 - Section de Vaucluse à Avignon</Title></root>"
"<?xml version='1.0' encoding='UTF-8'?><root available-locales="fr_FR" default-locale="fr_FR"><Title language-id="fr_FR">SD85 - Section de Vendée à La Roche-sur-Yon</Title></root>"
"<?xml version='1.0' encoding='UTF-8'?><root available-locales="fr_FR" default-locale="fr_FR"><Title language-id="fr_FR">SD35 - Section d'Ille et Vilaine à Rennes</Title></root>"
"<?xml version='1.0' encoding='UTF-8'?><root available-locales="fr_FR" default-locale="fr_FR"><Title language-id="fr_FR">SD37 - Section d'Indre et Loire à Tours</Title></root>"
"<?xml version='1.0' encoding='UTF-8'?><root available-locales="fr_FR" default-locale="fr_FR"><Title language-id="fr_FR">SD67 - Section du Bas-Rhin à Strasbourg</Title></root>"
"<?xml version='1.0' encoding='UTF-8'?><root available-locales="fr_FR" default-locale="fr_FR"><Title language-id="fr_FR">SD14 - Section du Calvados à Herouville-Saint-Clair</Title></root>"
#608 Général » ORDER BY sur colonne de type text » 14/01/2013 11:47:04
- ruizsebastien
- Réponses : 7
Bonjour,
J'ai une table avec un champ de type text (pas xml) qui contient des données du style :
<?xml version='1.0' encoding='UTF-8'?><root available-locales="fr_FR" default-locale="fr_FR"><Title language-id="fr_FR">CA942 - Centre d'appels de Paris</Title></root>
Je voudrais faire un order by sur ce champ mais je voudrais qu'il ne trie qu'à partir de " - Centre d'appels...." et qu'il ignore le début.
#609 Re : Général » PgBadger et fonctions » 11/01/2013 10:56:56
Merci.
C'est fait.
#610 Re : Général » PgBadger et fonctions » 10/01/2013 18:17:24
c'est dommage parce que du coup on doit se passer de pgbadger pour faire du tuning sur les requêtes de nos fonctions.
Beau travail quand même sur pgbadger.
#611 Re : Général » PgBadger et fonctions » 10/01/2013 17:49:23
Voici ce que nous avons dans un de nos cluster :
log_filename = 'postgresql-%Y%m%d-%Hheure.log'
logging_collector = on
log_truncate_on_rotation = off
log_directory = '/P0K2YY51_B/pg_log'
log_error_verbosity = terse
log_line_prefix = '%t [%p]: [%l-1] user=%u,db=%d '
#log_min_duration_statement = '2s'
#pour parametre log_statement : commentaire a remettre pour pgbadger
log_statement = all
log_rotation_age = 60
#parametres pour pg_stat_statements
#shared_preload_libraries=> chargement de 2 librairies
shared_preload_libraries = 'pg_stat_statements, auto_explain'
custom_variable_classes = 'pg_stat_statements, auto_explain'
pg_stat_statements.max = 10000
pg_stat_statements.track = all
#trace activite
track_functions = pl
#parametres explain plan
auto_explain.log_min_duration = '3s'
auto_explain.log_nested_statements=on
log_line_prefix = '%t [%p]: [%l-1] user=%u,db=%d'
log_min_duration_statement = 0
log_checkpoints = on
log_connections = on
log_disconnections = on
log_lock_waits = on
log_temp_files = 0
lc_messages='C'
Et voici à titre d'exemple ce que nous avons dans nos logs :
2013-01-10 16:16:05 CET [1234]: [22-1] user=mcod,db=choregie_dbLOG: temporary file: path "pg_tblspc/16385/PG_9.1_201105231/pgsql_tmp/pgsql_tmp1234.10", size 58129812
2013-01-10 16:16:05 CET [1234]: [23-1] user=mcod,db=choregie_dbSTATEMENT: INSERT INTO cot_justif (
idejuscalcot, ideelecot, val, utl, usg, lib)
SELECT nextval('cot_idejuscalcot_justifcalcot_seq'), m.idesq, j.val, j.utl,
j.usg, j.lib
FROM JUSTIFICATIF_TRV j
INNER JOIN MAPPINGCOT_TRV m ON m.ide=j.ideelecot limit 50000000
2013-01-10 16:16:23 CET [1234]: [24-1] user=mcod,db=choregie_dbLOG: duration: 2111611.243 ms plan:
Query Text: INSERT INTO cot_justif (
idejuscalcot, ideelecot, val, utl, usg, lib)
SELECT nextval('cot_idejuscalcot_justifcalcot_seq'), m.idesq, j.val, j.utl,
j.usg, j.lib
FROM JUSTIFICATIF_TRV j
INNER JOIN MAPPINGCOT_TRV m ON m.ide=j.ideelecot limit 50000000
Insert on cot_justif (cost=846419.11..5926987.55 rows=50000000 width=40)
-> Subquery Scan on "*SELECT*" (cost=846419.11..5926987.55 rows=50000000 width=40)
-> Limit (cost=846419.11..4926987.55 rows=50000000 width=32)
-> Hash Join (cost=846419.11..60353475.35 rows=729151552 width=32)
Hash Cond: (j.ideelecot = m.ide)
-> Seq Scan on justificatif_trv j (cost=0.00..14777438.52 rows=729151552 width=32)
-> Hash (cost=397686.16..397686.16 rows=25814716 width=16)
Buckets: 262144 Batches: 16 Memory Usage: 75690kB
-> Seq Scan on mappingcot_trv m (cost=0.00..397686.16 rows=25814716 width=16)
#612 Re : Général » PgBadger et fonctions » 10/01/2013 15:14:08
Bonjour,
En fait si on peut avoir les logs du détails des fonctions avec les paramètres adéquats dans postgresql.conf mais du coup ce n'est pas compatible avec pgbadger...
Peut être dans une prochaine version de pgbadger ?
#613 Général » PgBadger et fonctions » 10/01/2013 12:38:22
- ruizsebastien
- Réponses : 8
Bonjour,
Nous utilisons PgBadger (qui fonctionne très bien) mais nous aimerions savoir s'il est possible d'avoir le détail de l'exécution d'une fonction (toutes les requêtes qui sont exécutées par cette fonction). Car par défaut, PgBadger se contente d'afficher seulement la durée de la fonction entière mais pas le détail.
#614 Re : Général » [RESOLU] ERROR: cached plan must not change » 31/12/2012 10:59:50
Bonjour,
Nous ne sommes pas parvenu à vider le cache du driver jdbc avec une méthode java.
Mais nous avons réussi à contourner le problème en tuant les sessions des users transactionnels (pg_terminate_backend) au niveau du cluster après un changement DDL ce qui a pour effet de forcer l'application à ouvrir de nouvelles sessions et donc de demander un nouveau cache au driver jdbc.
Si ça peut aider quelqu'un qui rencontre le même problème...
Merci aux contributeurs pour l'aide apportée et bonnes fêtes de fin d'années à tous !
#615 Re : Général » [RESOLU] ERROR: cached plan must not change » 20/12/2012 13:02:11
Merci pour cette réponse.
Nous avons trouver également la méthode clearStatementCache() qui pourrait nous dépanner.
Je mettrais à jour ce file de discussion si nous avons réussi avec une de ces 2 méthodes.
#616 Re : Général » [RESOLU] ERROR: cached plan must not change » 20/12/2012 12:39:07
Bonjour Marc,
Merci pour votre réponse.
Concrètement comment doit-on faire ?
#617 Re : Général » [RESOLU] ERROR: cached plan must not change » 20/12/2012 12:14:37
Bonjour Guillaume,
Pour pg_prepared_statements c'est que nous avions compris.
Pour supprimer les plans en cache : comme faire à part relancer le WAS ?
#618 Général » [RESOLU] ERROR: cached plan must not change » 20/12/2012 10:50:21
- ruizsebastien
- Réponses : 8
Bonjour,
Nous rencontrons depuis quelque temps cette erreur :
ERROR: cached plan must not change
Voici notre situation :
WAS >> hibernate >> appli >> pool de connexion >> drivers jdbc >> cluster postgresql 9.1.2
L'application génère des prepared statements qui sont persistants dans le cache du driver JDBC.
Si on modifie le DDL (ajout de colonne, modification de la taille d'un champ, etc...) sur une des tables concernées par la requête stockée dans le cache jdbc, on obtient l'erreur cached plan must not change.
Notre solution est de forcer le vidage du cache jdbc en redémarrant le WAS (ce qui n'est pas acceptable puisque le WAS héberge d'autres applications).
La vue pg_prepared_statements ne donne rien, on ne voit pas les prepared statements. Donc on ne peut pas faire de deallocate.
Connaissez vous une solution de contournement à ce problème ?
Merci.