Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Environnement :
PostgreSQL 9.0.4 sur WindowsServer2008
Client MS-Access 2007 lié à une base de données PostgreSQL
Le type booléen entre un client MS-Access (quelle que soit la version) et un serveur PostgreSQL pose problème.
MS-Access envoie à PostgreSQL -1 pour true et 0 pour false.
Lorsqu'une clause WHERE du client comporte une expression utilisant un champ de type booléen elle ne peut pas être évaluée par PostgreSQL.
Ce qui déclenche l’erreur suivante :
ERROR: operator does not exist: boolean = integer
Pour résoudre ce problème nous avons surchargé l'opérateur d'égalité afin qu'il accepte ce type d'argument en créant un opérateur, qui lui appelle une fonction personnalisée pour effectuer la comparaison
create function prospicio_dvlp_demo.integer2boolean (boolean, integer) returns boolean as '
begin
if $1 isnull then
return null;
end if;
if $1 is true then
if $2 <> 0 then
return true;
end if;
else
if $2 = 0 then
return true;
end if;
end if;
return false;
end;
' language 'plpgsql';
create operator prospicio_dvlp_demo.= (
leftarg = boolean,
rightarg = integer,
procedure = integer2boolean,
commutator = '=',
negator = '<>',
restrict = eqsel,
join = eqjoinsel
);
Le problème :
- L'opérateur et la fonction se trouvent dans un schéma nommé, autre que public.
- Le chemin de recherche des objets de base de données est le schéma de même nom que l'utilisateur connecté et pg_catalog.
- Les utilisateurs ne sont pas propriétaire du schéma contenant l'opérateur surchargé, donc, celui-ci n'est pas trouvé.
- Il n’est semble-t-il pas possible de donner des droits sur l’opérateur créé, malgré que cet opérateur soit un objet. De toute manière, cela ne résoudrait pas nécessairement le problème.
A votre avis y a-t-il moyen de faire en sorte que cet opérateur soit "trouvé" sans le mettre dans le schéma public de la base de données?
D'avance merci pour vos conseils.
Sylvie
La migration vers la version 9.0.4 de mon serveur PostgreSQL est planifiée pour la semaine prochaine!
Merci pour ces conseils dans l'ajustement de ce paramètre work_mem.
Sylvie
Bonjour,
Merci pour votre réponse rapide, claire et précise! Vous êtes toujours aussi efficace!
Effectivement, en augmentant la valeur de ce paramètre pour la session, l'exécution de la requête dure 5 secondes.
Cela me montre que j'ai encore bien des compétences à acquérir dans l'administration d'un serveur PostgreSQL!
Bonne journée!
Sylvie
Voici à titre documentaire le résultat de mon test avec le même jeu de données que précédemment :
spagobi_stagingarea=> set work_mem to '128MB';
SET
spagobi_stagingarea=> EXPLAIN DELETE FROM HISTO_PersoHoraires
spagobi_stagingarea-> WHERE Numero NOT IN
spagobi_stagingarea-> (SELECT Numero_TEC FROM KEEP_PersoHoraires)
spagobi_stagingarea-> AND DateArchivage IS NULL;
QUERY PLAN
------------------------------------------------------------------------------------
Seq Scan on histo_persohoraires (cost=26056.00..63284.85 rows=689978 width=6)
Filter: ((datearchivage IS NULL) AND (NOT (hashed SubPlan 1)))
SubPlan 1
-> Seq Scan on keep_persohoraires (cost=0.00..22856.00 rows=1280000 width=8)
(4 rows)
spagobi_stagingarea=> EXPLAIN ANALYSE DELETE FROM HISTO_PersoHoraires
spagobi_stagingarea-> WHERE Numero NOT IN
spagobi_stagingarea-> (SELECT Numero_TEC FROM KEEP_PersoHoraires)
spagobi_stagingarea-> AND DateArchivage IS NULL ;
QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------
Seq Scan on histo_persohoraires (cost=26056.00..63284.85 rows=689978 width=6) (actual time=5004.884..5004.884 rows=0 loops=1)
Filter: ((datearchivage IS NULL) AND (NOT (hashed SubPlan 1)))
SubPlan 1
-> Seq Scan on keep_persohoraires (cost=0.00..22856.00 rows=1280000 width=8) (actual time=0.047..1700.607 rows=1383508 loops=1)
Total runtime: 5010.056 ms
(5 rows)
Bonjour,
Contexte :
Etude de faisabilité pour une migration SQLServer 2005 vers PostgreSQL 8.4.3 d'un projet de Datawarehouse (modeste)
Environnement :
PostgreSQL 8.4.3 sur WindowsServer2008
Client pgAdmin sur un poste de travail WindowXP
Client psql sur un poste de travail WindowXP
Problème : Durée d'exécution d'une requête SQL dans les traitements ETL sous PostgreSQL
La requête :
DELETE FROM HISTO_PersoHoraires
WHERE Numero NOT IN
(SELECT Numero_TEC FROM KEEP_PersoHoraires)
AND DateArchivage IS NULL
Volume des données pour tests :
Table HISTO_PersoHoraires : 1'383'508 lignes
Table KEEP_PersoHoraires : 1'383'508 lignes
Nombre de lignes satisfaisant le critère DateArchivage IS NULL : 1'379'998
Durée d'exécution :
Dans SQLServer - Environ 10 minutes
Dans PostgreSQL - Après 6h30 la requête est toujours en cours d'exécution
Structure des tables :
spagobi_stagingarea=> \d histo_persoHoraires
Table "spagobi.histo_persohoraires"
Column | Type | Modifiers
---------------------------+--------------------------------+-----------
numero | numeric(18,0) | not null
num_formations | numeric(18,0) |
num_lieuxdeformations | numeric(18,0) |
num_persomodules | numeric(18,0) |
num_justifications | numeric(18,0) |
num_periodesenseignements | numeric(18,0) |
ladate | timestamp(6) without time zone |
estabsent | numeric(18,0) | not null
estenvacances | numeric(18,0) |
datearchivage | timestamp(6) without time zone |
luetarchive | numeric(18,0) |
ajuser | character varying(120) |
ajdate | timestamp(6) without time zone |
mouser | character varying(120) |
modate | timestamp(6) without time zone |
mocount | numeric(18,0) |
Indexes:
"histo_persohoraires_pkey" PRIMARY KEY, btree (numero)
"xu_ladate" btree (ladate)
"xu_num_lieuxdeformations" btree (num_lieuxdeformations)
"xu_num_persomodules" btree (num_persomodules)
spagobi_stagingarea=> \d keep_persoHoraires
Table "spagobi.keep_persohoraires"
Column | Type | Modifiers
------------+---------------+--------------------------------------------------------------
numero | numeric(18,0) | not null default nextval('seq_keep_persohoraires'::regclass)
numero_tec | numeric(18,0) | not null
Indexes:
"pk_keep_persohoraires" PRIMARY KEY, btree (numero)
Plan d'exécution de la requête :
spagobi_stagingarea=> EXPLAIN DELETE FROM HISTO_PersoHoraires
spagobi_stagingarea-> WHERE Numero NOT IN
spagobi_stagingarea-> (SELECT Numero_TEC FROM KEEP_PersoHoraires)
spagobi_stagingarea-> AND DateArchivage IS NULL;
QUERY PLAN
------------------------------------------------------------------------------------------
Seq Scan on histo_persohoraires (cost=29136.00..14526900364.85 rows=689978 width=6)
Filter: ((datearchivage IS NULL) AND (NOT (SubPlan 1)))
SubPlan 1
-> Materialize (cost=29136.00..46936.00 rows=1280000 width=8)
-> Seq Scan on keep_persohoraires (cost=0.00..22856.00 rows=1280000 width=8)
Mes questions :
Ce problème provient-il d'un mauvais paramétrage de mon serveur base de données?
Devrais-je indexer différemment certaines colonnes?
Avez-vous une piste de recherche à m'indiquer?
Cela m'ennuie un peu de retravailler sur la requête car pour une première étude nous
voulions faire une migration 1-1, c'est-à-dire réécrire les traitements tels quels afin d'avoir un
comparatif des 2 environnements.
D'avance merci pour vos avis
Sylvie
Même problème !
Merci pour les tests effectués et n'oubliez pas de prendre un peu de vacances!
En attendant des nouvelles je vous souhaite un Joyeux Noël!
Sylvie
Pour votre gouverne, il me semble que lorsque j'étais en version 8.3.4 la commande CREATE TABLE (depuis le client psql) avec des caractères accentués dans les noms de colonne provoquait une erreur. De ce fait, je n'avais pas de problème avec mes backups.
Merci pour votre réponse.
Malheureusement, l'indication de l'encodage avec l'option -E ne donne pas le résultat attendu.
Auriez-vous une autre proposition?
C:\postgres\84\bin>pg_dump -i -h localhost -p 5434 -U postgres -E utf8 -F c -f C:\temp\test.backup test
pg_dump: la commande SQL a échoué
pg_dump: Message d'erreur du serveur : ERROR: invalid byte sequence for encoding "UTF8": 0xe3a96e
ASTUCE : This error can also happen if the byte sequence does not match the encoding expected by the server, which is controlled by "client_encoding".
pg_dump: La commande était : COPY bouchard.test_accent (nom, "prã©nom") TO stdout;
Bonjour,
J'administre des BD PostgreSQL pédagogiques et j'aimerais paramétrer mon serveur pour que les noms de colonnes avec accent soient refusés. D'une part cela va à l'encontre des bonnes pratiques que j'utilise et d'autre part cela met les backup en erreur ce qui est plus embêtant!
Quelqu'un peut-il me dire comment procéder?
Environnement :
PostgreSQL 8.4.3 sur WindowsServer2008
Client psql sur un poste de travail WindowXP
C:\clientPostgres>chcp
Page de codes active : 1252
test=> show client_encoding;
client_encoding
-----------------
win1252
test=> show server_encoding;
server_encoding
-----------------
UTF8
CREATE TABLE test_accent (
Nom VARCHAR(50),
Prénom VARCHAR(50)
);
CREATE TABLE
test=> \d test_accent
ERROR: invalid byte sequence for encoding "UTF8": 0xe3a96e
HINT: This error can also happen if the byte sequence does not match
the encoding expected by the server, which is controlled by "client_encoding".
-- Lors du backup avec pg_dump
...
pg_dump: dumping contents of table test_accent
pg_dump: SQL command failed
pg_dump: Error message from server: ERROR: invalid byte sequence for encoding "UTF8": 0xe3a96e
HINT: This error can also happen if the byte sequence does not match the encoding expected by the server, which is controlled by "client_encoding".
pg_dump: The command was: COPY bouchard.test_accent (nom, "prã©nom") TO stdout;
pg_dump: *** aborted because of error
Par avance merci!
Sylvie
Merci pour votre réponse claire et précise.
C'est effectivement la bonne solution!
Je pense que c'est une bonne pratique que je vais adopter .
J'en profite pour signaler que j'apprécie énormément la qualité de vos réponses en général et la rapidité de réaction que vous avez!
Bravo!
Sylvie
Bonjour,
J'ai un problème d'encodage des caractères lorsque je lance un script depuis phpPgadmin
Ma configuration :
PostgreSQL 8.4.3 sur Windows Server 2008
Base de données en UTF8
Un client phpPgAdmin 5.0-beta2 (PHP 5.2.8)
Les commandes suivantes exécutées depuis la fenêtre SQL s'exécutent normalement
CREATE TABLE test (c1 INTEGER, c2 VARCHAR(20));
INSERT INTO test VALUES (1, 'été');
le tupe est inséré.
Je lance un script SQL contenant deux commandes :
INSERT INTO test VALUES (2, 'maison');
INSERT INTO test VALUES (3, 'fête');
Le premier tuple est bien inséré mais pas le second.
Problème d'encodage des caractères.
Voici le message :
INSERT 0 1
data.sql:2: ERROR: invalid byte sequence for encoding "UTF8": 0xea7465
HINT: This error can also happen if the byte sequence does not match the encoding expected by the server, which is controlled by "client_encoding".
Le fait que l'encodage soit correct pour les commandes exécutées depuis
la fenêtre SQL mais pas depuis celle permettant de lancer des scripts me semble
bizarre. Je vois que ce ne sont pas les mêmes fichiers php qui sont
sont utilisés et je ne suis pas une spécialiste php...
Savez-vous dans quel fichier php cette configuration doit être faite et comment ?
D'avance merci!
Sylvie
Bonjour,
Dans un environnement windows, initdb ne doit pas être exécuté par un utilisateur ayant des droits administrateur. Il faut créer un utilisateur ne faisant pas partie du groupe Administrateur et c'est ce dernier qui doit lancer initdb.
Sylvie
Quelques éléments nouveaux :
- Pas de changement après paramétrage de l'autovacuum à off, j'ai toujours une multitude d'erreurs dans l'observateur d'événements,
- J'ai trouvé le moyen d'obtenir des messages plus clairs dans l'observateur d'événements de Windows :
En fait, il faut enregistrer la bibliothèque eventlog sur Windows. Cela permet de créer les entrées de registre utilisées par l'observateur d'événements.
Voici la commande à exécuter depuis une console DOS :
regsvr32 chemin_librairies_psql/pgevent.dll
et le lien où j'ai trouvé cette info http://docs.postgresqlfr.org/8.3/INSTALL.html
Le message du début de cette discussion devient ainsi :
n'a pas pu écrire dans le journal applicatif : Bad file descriptor
Je continue mes recherches du côté de l'anti-virus.
Par contre je n'arrive pas à obtenir les messages en anglais dans les logs. J'ai bien mis lc_messages = 'C' puis j'ai redémarré le serveur mais ils sont toujours en français. Je ne trouve pas la liste des valeurs possibles pour ce paramètre dans la doc. Avez-vous une autre proposition?
Merci
Sylvie
L'utilisateur des services Postgres a les droits d'écriture sur les répertoires pg_log de chaque cluster puisqu'un nouveau fichier y est créé chaque jour.
Malheureusement, son contenu ne me permet pas de détecter la source des erreurs signalées dans l'observateur d'événements qui contient si peu d'information sur ces erreurs.
Pour ce qui est de l'anti-virus, j'ai demandé au responsable système d'exclure la surveillance de ce répertoire par l'anti-virus du serveur. Dès que j'aurai plus d'infos je vous les transmettrai.
Je me pose une question : Etant donné que ces erreurs apparaissent toutes les n minutes pensez-vous que cela puisse être en lien avec l'auto-vaccum? Mais, comme il n'y pas d'erreurs signalées la nuit je ne pense pas que ce soit le cas.
Une autre question : Pensez-vous que cela puisse provenir de l'encodage des caractères? Lorsque j'ai migré de la version 8.2.3 vers la version 8.3.4 la locale du serveur a été prise par défaut et tous les messages sont en français. Dans les logs, il y a des problèmes d'encodage avec les caractères accentués.
Bref, je ne sais pas trop dans quelle direction orienter mes recherches. Mon premier objectif était d'essayer d'obtenir des messages plus explicites dans les erreurs de l'observateur d'événements.
Merci
Sylvie
En fait, ce paramètre est à ON. J'ai voulu limiter le volume du code à vous présenter mais ce n'était pas une bonne idée. Je m'en excuse.
Voici le contenu intégral de 2 sections du fichier postgreql.conf
Dans le répertoire pg_log je génère un fichier par jour mais avec le paramétrage que j'ai fait, j'ai principalement des informations sur les commandes SQL. Donc peu d'aide pour le problème actuel à savoir les erreurs de l'observateur d'événements.
Merci
Sylvie
#------------------------------------------------------------------------------
# ERROR REPORTING AND LOGGING
#------------------------------------------------------------------------------
# - Where to Log -
#log_destination = 'stderr' # Valid values are combinations of
# stderr, csvlog, syslog and eventlog,
# depending on platform. csvlog
# requires logging_collector to be on.
# This is used when logging to stderr:
#logging_collector = off # Enable capturing of stderr and csvlog
# into log files. Required to be on for
# csvlogs.
# (change requires restart)
logging_collector = on
# These are only used if logging_collector is on:
#log_directory = 'pg_log' # directory where log files are written,
# can be absolute or relative to PGDATA
#log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log' # log file name pattern,
# can include strftime() escapes
log_filename = 'postgresql-%Y-%m-%d.log'
#log_truncate_on_rotation = off # If on, an existing log file of the
# same name as the new log file will be
# truncated rather than appended to.
# But such truncation only occurs on
# time-driven rotation, not on restarts
# or size-driven rotation. Default is
# off, meaning append to existing files
# in all cases.
#log_rotation_age = 1d # Automatic rotation of logfiles will
# happen after that time. 0 to disable.
#log_rotation_size = 10MB # Automatic rotation of logfiles will
# happen after that much log output.
# 0 to disable.
# These are relevant when logging to syslog:
#syslog_facility = 'LOCAL0'
#syslog_ident = 'postgres'
# - When to Log -
#client_min_messages = notice # values in order of decreasing detail:
# debug5
# debug4
# debug3
# debug2
# debug1
# log
# notice
# warning
# error
#log_min_messages = notice # values in order of decreasing detail:
# debug5
# debug4
# debug3
# debug2
# debug1
# info
# notice
# warning
# error
# log
# fatal
# panic
#log_error_verbosity = default # terse, default, or verbose messages
#log_min_error_statement = error # values in order of decreasing detail:
# debug5
# debug4
# debug3
# debug2
# debug1
# info
# notice
# warning
# error
# log
# fatal
# panic (effectively off)
log_min_error_statement = notice
#log_min_duration_statement = -1 # -1 is disabled, 0 logs all statements
# and their durations, > 0 logs only
# statements running at least this time.
#silent_mode = off # DO NOT USE without syslog or
# logging_collector
# (change requires restart)
# - What to Log -
#debug_print_parse = off
#debug_print_rewritten = off
#debug_print_plan = off
#debug_pretty_print = off
#log_checkpoints = off
#log_connections = off
#log_disconnections = off
#log_duration = off
log_duration = on
#log_hostname = off
#log_line_prefix = '' # special values:
# %u = user name
# %d = database name
# %r = remote host and port
# %h = remote host
# %p = process ID
# %t = timestamp without milliseconds
# %m = timestamp with milliseconds
# %i = command tag
# %c = session ID
# %l = session line number
# %s = session start timestamp
# %v = virtual transaction ID
# %x = transaction ID (0 if none)
# %q = stop here in non-session
# processes
# %% = '%'
# e.g. '<%u%%%d> '
log_line_prefix = '%t [%p]: [%l-1] db=%d,user=%u,statement=%i '
#log_lock_waits = off # log lock waits >= deadlock_timeout
#log_statement = 'none' # none, ddl, mod, all
log_statement = 'mod'
#log_temp_files = -1 # log temporary files equal or larger
# than specified size;
# -1 disables, 0 logs all temp files
#log_timezone = unknown # actually, defaults to TZ environment
# setting
Bonsoir,
Globalement, j'ai mis en place quelques tracages de commandes sql exécutées. J'ai donc un fichier par jour dans le répertoire pg_log mais tel qu'il est actuellement, il ne contient pas d'informations utiles pour ce problème.
Voici quelques paramétrages de cette section. Pour la majorité des lignes j'ai laissé les valeurs par défaut.
#log_destination = 'stderr'
#logging_collector = off
#log_directory = 'pg_log'
log_filename = 'postgresql-%Y-%m-%d.log'
#client_min_messages = notice
#log_min_messages = notice
#log_error_verbosity = default
#log_min_error_statement = error
log_min_error_statement = notice
log_duration = on
log_line_prefix = '%t [%p]: [%l-1] db=%d,user=%u,statement=%i '
log_statement = 'mod'
Une proposition?
Merci d'avoir répondu aussi rapidement!
Sylvie
Bonjour,
J'ai une installation de PostgreSQL 8.3.5 sur un serveur dédié avec Windows Server 2003.
J'ai 3 clusters sur cette installation.
L'un de ces clusters est dédié à des bases de données utilisées par opencms. Un seul utilisateur fait les accès aux différentes bases de ce cluster.
Le nombre d'erreurs journalières signalé par l'observateur d'événements de windows est important, environ 150 depuis ce matin, et ce même lorsqu'il y peu de connexions sur les bases de données. Toutes les quelques minutes une nouvelle erreur est signalée.
Les informations sont pauvres :
Type de l'événement : Erreur
Source de l'événement : PostgreSQL
Catégorie de l'événement : Aucun
ID de l'événement : 0
Date : 17.06.2009
Heure : 14:42:47
Utilisateur : N/A
Ordinateur : HESTIA
Description :
La description pour l'ID d'événement ( 0 ) dans la source (PostgreSQL) est introuvable. L'ordinateur local n'a peut-être pas les informations de Registre ou les librairies requises pour afficher les messages émanant d'un ordinateur distant. Vous pourrez peut-être utiliser l'option /AUXSOURCE= pour récupérer cette description. Reportez-vous aux rubriques Aide et support pour plus de détails. Les informations suivantes font partie de l'événement : n'a pas pu écrire dans le journal applicatif : Bad file descriptor
Quelqu'un aurait-il une idée pour orienter mes recherches?
Par avance merci
Sylvie
Merci pour la précision de la réponse.
Il faudra que je prenne le temps de creuser la gestion des droits sous Windows pour mettre en place la meilleure sécurité.
Sylvie
Bonjour,
Merci pour votre réponse.
Je viens de faire le changement et tout s'est bien déroulé..
Je comprends votre remarque quant aux droits sur le répertoire / sous-répertoires d'un cluster. Il est évident qu'aucun utilisateur ne doit avoir un accès direct à ce répertoire via un système de fichiers.
Une question : Laissez-vous les droits en écriture au super-utilisateur style root ?
Bonne journée
Sylvie
Bonjour,
J'ai une installation de PostgreSQL 8.2.3 sur Windows Server 2003.
J'ai créé le premier cluster de bases de données (par initdb) dans le sous-répertoire Data de l'arborescence de base.
J'aimerais déplacer ce cluster sur un autre disque.
A votre avis, la démarche suivante est-elle correcte ?
- J'arrête le service
- Je déplace le dossier Data
- J'adapte ce nouveau chemin dans la commande de démarrage du service
- Je donne les droits en écriture sur ce répertoire à l'utilisateur qui lance le service.
- Et je redémarre le service
D'avance merci de votre réponse
Sylvie
Pages : 1