Vous n'êtes pas identifié(e).
Pages : 1
Bonjour à tous,
J'ai de temps en temps besoin de remplacer une chaîne d'octets par une autre dans des données de type BYTEA.
En gros ce serait faire l'équivalent pour du BYTEA de la fonction replace() pour les données de type textuel.
Malheureusement, cette fonction n'existe pas en standard, et regexp_replace() ne porte lui aussi que sur du texte.
A part écrire une fonction replace(string bytea, from bytea, to bytea) en C, quelqu'un aurait-il une solution alternative de "moins bas niveau" ?
Merci par avance pour votre aide.
Cordialement.
Philippe.
Bonjour à tous,
J'ai l'impression que la liste des entrées dans la section Planète PostgreSQL s'est arrêtée au 12 février. Or il y a au moins d'autres "Nouvelles Hebomadaires depuis", et, en principe un petit billet que j'ai émis récemment et qui devrait normalement être référencé (si j'ai bien mis les bons tags !).
Bien cordialement.
Philippe Beaudoin
Merci Guillaume.
J'ai effectivement traité mon problème par le SQL que tu proposes.
Ma question portait bien sur la capacité de faire l'équivalent avec phppgadmin.
Je crains donc qu'il ne faille patcher ;-)
Philippe.
Bonjour,
Existe-t'il un moyen de changer le tablespace pour un index ? (autrement qu'en tapant une requête SQL)
(j'ai trouvé comment changer le tablespace d'une table, mais pas d'un index)
De la même manière, existe-t'il un moyen de changer le tablespace par défaut d'une base de données ?
Cordialement.
Philippe Beaudoin.
Bonjour,
J'utilise pg 9.1.1
Je tente la mise en place d'un cluster esclave avec la S-R.
Mais ma commande pg_basebackup me retourne rapidement un message indiquant que la directory citée existe mais n'est pas vide.
La commande lancée depuis le serveur secondaire :
pg_basebackup -D /exploit/base/pgdata -h <ip du serveur principal> -p 5501 -U replication -Pv -c fast
Le seul message retourné :
pg_basebackup: directory "/exploit/base/pgdata" exists but is not empty
Avant de lancer la commande, la directory pgdata n'existe pas.
Après l'exécution, j'ai une directory pgdata effectivement créée et ne contenant qu'une sous-directory correspondant au contenu complet d'un tablespace
Mais aucun autre fichier ou répertoire du cluster
Le log du cluster maitre contient :
<2012-04-13 11:02:18.998 CEST replication [unknown] 28429>LOG: could not send data to client: Connexion ré-initialisée par le correspondant
<2012-04-13 11:02:18.998 CEST replication [unknown] 28429>FATAL: base backup could not send data, aborting backup
<2012-04-13 11:02:18.998 CEST replication [unknown] 28429>LOG: could not send data to client: Relais brisé (pipe)
Voici les éléments de configuration du cluster maître :
listen_addresses = '*'
port = 5501
max_connections = 20
shared_buffers = 512MB
work_mem = 2MB
maintenance_work_mem = 48MB
checkpoint_segments = 16
checkpoint_completion_target = 0.9
logging_collector = on
log_filename = 'postgresql-%d.log'
log_truncate_on_rotation = on
log_line_prefix = '<%m %u %d %p>'
max_locks_per_transaction = 200
wal_level = hot_standby
archive_mode = on
archive_command = 'cp %p /exploit/base/archivage/%f'
archive_timeout = 300 # pour forcer un changement de log après 5 minute maximum
max_wal_senders = 1
Mon cluster maitre fonctionne bien, avec l'archivage des WAL.
Le role 'replication' destiné à ... la réplication, a l'air de bien fonctionné lui aussi.
Peut-être y a t-il une particularité ici : j'ai un tablespace qui est physiquement implanté dans le répertoire pgdata (oui, c'est fait volontairement !)
Une idée pour aller plus loin ?
Merci par avance.
Cordialement. Philippe.
2 choses pour clore le sujet :
- ouf, j'ai compris pourquoi ce ne serait pas une bonne idée que psql fasse la résolution des variables dans les noms de fichier de la commande \copy : on ne pourrait tout simplement plus gérer de fichier dont le nom contiendrait un caractère ':',
- la solution que nous allons mettre en oeuvre va consister à remplacer dans le shell script appelant psql la commande
psql ... -f <script.sql> -v var=...
par une commande
sed 's/:var/.../' <script.sql> | psql ...
Ainsi le fichier script fourni restera unique et la substitution se fera à l'appel de psql.
A+ Philippe.
Bonjour à tous,
On m'a intérrogé aujourd'hui sur un problème d'utilisation de psql (actuellement en 8.3, demain en 9.0).
Il s'agit de pouvoir utiliser une variable pour spécifier le nom d'un fichier dans une méta commande \copy from.
L'objectif final est d'exécuter le même script psql sur un grand nombre de bases, mais avec des arborescences différentes.
La variable décrivant le nom du fichier est passée par le script schell qui appelle psql (option -v). Là, pas de problème. La variable est bien utilisable, par \echo par exemple
Mais avec la commande \copy, on ne peut directement utiliser :varriable comme nom de fichier. (D'ailleurs je ne comprends pas bien pourquoi)
Pour un \copy to, une astuce consiste à faire une redirection juste avant la commande, avec \o :variable (et avec \o juste après pour arrêter la redirection) et d'utiliser STDOUT comme nom de fichier dans \copy. En clair :
\o :fichier
\copy <table.ou.requete> to STDOUT
\o
Mais dans l'autre sens, pour un \copy from, je ne trouve pas de solution.
J'ai bien tenté quelques variantes de \copy from STDIN, mais sans résultat.
L'utilisation de pstdin ne m'a rien apporté non plus.
Bref, si quelqu'un a une idée ?
Cordialement.
Philippe.
Bonjour,
J'ai eu la chance, en tant que consultant de la socité Bull, d'être au coeur de ce beau projet.
Je pense qu'un prochain pg-day france permettra de présenter en détail cette réalisation...
Juste pour ajouter quelques éléments a ce qui a déjà été indiqué :
Les 2 grosses applications qui utilisent aujourd'hui PostgreSQL, coeur du SI de la CNAF, sont en Cobol, représentant environ 20 Millions de lignes de code.
Les 168 clusters sont hébergés dans 10 partitions Linux dédiées (8 CP Xéon chacune).
Le volume global de données est de 4 To.
En tout, l'activité journalière (pour les grosses journées) entraîne l'exécution de 1 milliard de requêtes SQL !
L'architecture mise en place garantit un haut niveau de disponibilité (et nous poursuivons les travaux pour l'améliorer encore...).
Pour info, je présenterai brièvement ce projet vendredi prochain à l'Open World Forum à Paris.
A j'oubliais,
- nombre de problèmes postgresql rencontrés depuis le début du projet = 0 !!!
Philippe Beaudoin.
Bonjour,
Je développe actuellement un logiciel à base de fonctions plpgsql qui sont appelées dans des scripts psql et par du code php.
Elles doivent pouvoir être exécutées avec des versions de postgresql 8.2 et suivantes.
Certaines fonctions en appellent d'autres. Actuellement, lorsqu'une fonction quelconque détecte une anomalie, elle fait un simple RAISE EXCEPTION avec un message explicatif de l'erreur.
Pour diverses raisons, j'aimerais centraliser la gestion des erreurs dans une fonction dédiée.
En fait je souhaiterais qu'en cas d'erreur :
- les éventuelles opérations déjà effectuées sur la base soient rollbackées,
- une ligne soit insérée dans une table de log des erreurs,
- un message d'erreur soit retourné à l'application.
Mais j'avoue avoir du mal à structurer du code pour mettre en oeuvre ces principes.
Dit autrement, j'ai actuellement du code du style :
Create function FctA
begin
...
if <condition> then
raise exception 'erreur dans FctA';
…
end;
Et j'aimerais un fonctionnement du genre :
Create function FctA
begin
...
if <condition> then
perform FctErr ('erreur dans FctA');
R
Bonjour,
Je développe actuellement un logiciel à base de fonctions plpgsql qui sont appelées dans des scripts psql et par du code php.
Elles doivent pouvoir être exécutées avec des versions de postgresql 8.2 et suivantes.
Certaines fonctions en appellent d'autres. Actuellement, lorsqu'une fonction quelconque détecte une anomalie, elle fait un simple RAISE EXCEPTION avec un message explicatif de l'erreur.
Pour diverses raisons, j'aimerais centraliser la gestion des erreurs dans une fonction dédiée.
En fait je souhaiterais qu'en cas d'erreur :
- les éventuelles opérations déjà effectuées sur la base soient rollbackées,
- une ligne soit insérée dans une table de log des erreurs,
- un message d'erreur soit retourné à l'application.
Mais j'avoue avoir du mal à structurer du code pour mettre en oeuvre ces principes.
Dit autrement, j'ai actuellement du code du style :
Create function FctA
begin
...
if <condition> then
raise exception 'erreur dans FctA';
…
end;
Et j'aimerais un fonctionnement du genre :
Create function FctA
begin
...
if <condition> then
perform FctErr ('erreur dans FctA');
R
Pages : 1