Vous n'êtes pas identifié(e).

#1 Re : Général » [RESOLU] A propos de séquence et de start_value » 14/04/2017 09:17:26

Pourquoi réinitialiser ?
Votre séquence ne sert-elle pas qu'à assurer l'unicité de votre clé primaire ?

#2 Re : Installation » Installation plusieurs Version de Postgresql sur une même VM » 13/04/2017 14:10:17

Philippe PAVY a écrit :

tout se passe bien si les variables d'environnement sont correctement configurées.

Bonjour,

Je plussoie.

Cordialement,

Arkhena

#3 Re : Général » Nommer une table avec nom concaténé » 12/04/2017 11:17:35

Bonjour,

Il va vous falloir utiiser du SQL dynamic pour faire ça:
https://www.postgresql.org/docs/9.5/sta … namic.html

Cordialement,

Arkhena

#4 Re : Optimisation » configuer les valeurs de vm.dirty_background_bytes et devm.dirty_bytes » 12/04/2017 11:01:50

Effectivement, tant que vous ne voyez pas tourner l'instance, c'est compliqué de faire de l'optimisation...

Je suis surprise que le lien que vous citez ne parle pas de modifier le paramètre min_wal_size...

Bref, Avant de vous lancer dans la modification de vm.dirty_background_bytes et de vm.dirty_bytes, settez les paramètres basiques et voyez la fréquence de vos checkpoints. S'ils ont lieu plus souvent que checkpoint_timeout, ajustez le paramétrage. Si ensuite vous avez des soucis et que vous identifiez que ces soucis sont liés aux checkpoints, vous pourrez jouer avec dirty_background et dirty_bytes.

Cordialement,

Arkhena

NB: De manière générale, les serveurs n'étant de nos jours plus trop pauvres en RAM,  je mets WAL_buffers à 16 Mo pour pouvoir avoir un fichier entier en mémoire...

#5 Re : Optimisation » configuer les valeurs de vm.dirty_background_bytes et devm.dirty_bytes » 12/04/2017 09:18:43

Bonjour,

Avez-vous setté les paramètres "basiques" avant de toucher à ceux-là ?

Pour moi, les paramètres "basiques" sont:
    wal_buffers
    checkpoint_completion_target
    checkpoint_timeout
    en Version 9.4 et avant:
        checkpoint_segments
    En version 9.5 et après
        min_wal_size
        max_wal_size

Quelle valeur avez-vous assigné à ces paramètres?
Quelle fréquence de checkpoint voyez-vous dans les logs ?

Cordialement,

Arkhena

#6 Re : Général » Restauration à partir des snapshots de VM » 07/04/2017 09:36:29

ruizsebastien a écrit :

si tu relis ce fil depuis le début tu verras que je déconseille fortement de faire ça.
Chaque outil devrait faire ce pour quoi il est fait.
Snaphsot vmware pour l'OS.
Hotbackup postgresql pour les données.

Je plussoie!!!

#7 Re : Général » Restauration à partir des snapshots de VM » 03/04/2017 11:12:59

Philippe PAVY a écrit :

Je suis surpris de cette réponse: "petites bases et peu de transactions, il y a des chances que ça marche." !!!
Si on fait le start_backup, la sauvegarde, le stop_backup et que l'on sauvegarde l'ensemble des WAL générés pendant la sauvegarde, on doit pouvoir dans tous les cas restaurer l'instance, NON ? Je dirais même que quand on a beaucoup de volume, ce type de sauvegardes est tout de même bien plus rapide et tout à fait valide, je me trompe ?
Merci pour vos réponses sur le sujet.
Philippe

Effectivement, mais je n'avais pas compris que vous sauvegardiez aussi les WALs...
Par contre, j'ai toujours tendance à préférer utiliser les outils standards éprouvés plutôt que de reposer sur des sur-couches technologiques que je maîtrise moins. Donc barman, backrest ou wal-e... Mais ce n'est que ma vision des choses et la votre peut être valable aussi.

Pour revenir sur la discussion, il manque à mon sens deux informations vitales pour savoir quel type de sauvegarde mettre en place:
- Quelle est la durée maximale d'interruption admissible ?
- Combien de temps dure votre opération de restauration ?

Sans ces informations, nous ne pouvons que faire des spéculations...

Cordialement,

Arkhena

#8 Re : PSQL » pb syntaxe psql copy from stdin » 31/03/2017 19:12:48

Bonjour,

Copy vous permet de gérer les données pas les structures. Créez votre table d'abord.
(Assurez-vous également que le search_path comporte bien le schéma.)

Cordialement,

Arkhena

#9 Re : Général » Restauration PITR et recovery_target_xid » 31/03/2017 19:10:41

Bonjour,

Vous pouvez essayer de lire le WAL avec pg_xlogdump ( https://www.postgresql.org/docs/9.6/sta … gdump.html ).
Vous pouvez aussi procéder par tâtonnement sur le timestamp.

Bon courage,

Arkhena

#10 Re : Général » Restauration à partir des snapshots de VM » 30/03/2017 09:16:30

Bonjour,

Effectivement, dans le cas de petites bases avec peu de transaction, il y a des chances que ça marche. En faisant un start_backup, puis un stop_backup, vous augmentez les chances que ça se passe bien (mais assurez-vous de bien archiver vos WAL ailleurs). Dès que vous atteindrez un certain volume et un certain nombre de transactions, vos sauvegardes ne vaudront plus rien.

En tant que DBA, je ne prendrai jamais le risque de reposer sur de la chance pour mes sauvegardes.

Donc, mise en place de l'archivage continu et sauvegardes physiques régulières des bases avec l'outil prévu pour ça (barman ou backrest, mais il y en a d'autres).

À vous de voir quels sont vos objectifs de perte de données maximale admissible et durée maximale d'interruption admissible.

Cordialement,

Arkhena

#11 Re : Réplication » pg_basebackup >>> unrecognized configuration parameter replication » 16/03/2017 11:18:58

Bonjour,

Effectivement, c'est étrange. pg_basebackup n'existe pas en 8.4: https://www.postgresql.org/docs/8.4/sta … lient.html
Avez-vous plusieurs client postgres installés sur votre machine. Pourvez-vous lancer pg_basebackup avec l'option --version ?
La doc 8.4 existe toujours, je me demande si le problème n'est pas lié au forum qui trouve le lien trop long...

Cordialement,

Arkhena

#12 Re : Réplication » Sauvegarde physique » 16/03/2017 11:12:55

Bonjour,

La sauvegarde logique ne vous donne que l'état des données à un instant T.
La sauvegarde physique vous permet de revenir au plus près de vos données (si vous avez les WAL correspondant).

Prenons un exemple:
- Vous faites une sauvegarde logique toutes les nuits à 2h00
- Vous avez un crash à 10h00
-> Votre restauration vous fera perdre toutes les transactions commitées entre 2h00 et 10h00.

- Maintenant, vous faites une sauvegardes physique à 2h00 tous les matins. De plus vous avez mis en place l'archivage des Wal
- Vous avez un crash à 10h00
-> Votre restauration ne vous fera perdre aucune transaction commitée

De plus, la sauvegarde physique vous permet de faire du PITR (Point In Time Recovery).
Imaginons le scénario suivant:
Le développeur se trompe et envoie un DELETE sans la clause WHERE sur la base de production. Il committe sa transaction avant de se rendre compte de son erreur.
La sauvegarde logique fera là encore perdre tous les changements commités entre la date et l'heure de la sauvegarde et la date et l'heure de l'incident.
La sauvegarde physique permet de revenir juste avant l'erreur du développeur.

Enfin, de manière générale, la sauvegarde/restauration physique dure moins longtemps que son homologue logique (cet argument n'est bien sûr valable que pour les bases conséquentes).

Cordialement,

Arkhena

#13 Re : PgAdmin3 » erreur requête copy » 14/03/2017 09:02:19

Bonjour,

Il y a peut-être un point-virgule de trop en fin de ligne ?

Cordialement,

Arkhena

#14 Re : PgAdmin3 » problème mot de passe pour connexion » 13/03/2017 14:58:29

Ok, cela fait partie des trucs qu'on m'a dits il y a très longtemps et que j'ai intégrés sans me poser de questions (shame)...
Je viens de vérifier et effectivement, rien dans la doc ne va dans ce sens...

J'ai trouvé un forum (mais après de longues recherches) où un gars va dans ce sens (http://serverfault.com/questions/110154 … ew-install) mais sans l'étayer de preuves formelles, donc ça n'a pas de valeur...

#15 Re : PgAdmin3 » problème mot de passe pour connexion » 13/03/2017 10:58:33

Bonjour,

Je dis peut-être une bêtise, mais j'avais toujours entendu dire qu'il ne fallait jamais se connecter avec le user OS postgres, qu'il n'avait pas de password pour qu'on ne puisse pas se connecter avec et que c'était très bien comme ça... On m'a dit des co****ries ?

Cordialement,

Arkhena

#16 Re : Général » Gestion des logs » 09/03/2017 09:40:12

Bonjour,

Cela se paramètre dans le fichier postgresql.conf.
Vous trouverez toutes les informations nécessaires sur cette page: https://www.postgresql.org/docs/9.6/sta … gging.html
Regardez notamment le paramètre log_filename.

Cordialement,

Arkhena

#17 Re : PSQL » substitution de variables » 28/02/2017 14:36:31

Bonjour,

A ma connaissance, il n'est pas possible d'utiliser des variables dans le DDL en PostgreSQL (mais je peux me tromper et je n'ai pas trouvé de page de la documentation qui allait dans ce sens).
Par contre, le wiki PostgreSQL propose d'encapsuler le code dans une fonction:  https://wiki.postgresql.org/wiki/Dynamic_DDL

Bonne journée,

Arkhena

#18 Re : PL/pgSQL » trigger on delete » 20/02/2017 11:19:31

Bonjour,


Je ne suis pas fan des triggers qui ralentissent le DML...


Je vais donc commencer par répondre à côté (et je m'en excuse, vous êtes libres de sauter ce paragraphe):
A priori, ce que je comprends de votre besoin, c'est que vous voulez empêcher les DELETE physiques pour les remplacer par des DELETE logiques. Dans ce cas, pourquoi ne pas faire un REVOKE du droit de DELETE sur cette table (ou cet ensemble de données) pour imposer de faire des UPDATE permettant un DELETE logique ? Vous trouverez les informations sur le REVOKE ici: https://www.postgresql.org/docs/9.6/sta … evoke.html


Sinon, vous pouvez créer un trigger INSTEAD OF. Vous trouverez la documentation ici: https://www.postgresql.org/docs/9.6/sta … igger.html


Cordialement,


Arkhena

#19 Re : Général » Ajout d'une colonne à un endroit précis » 20/02/2017 10:01:40

Bonjour,

La doc postgreSQL propose de créer un vue avec l'ordre des colonnes que vous souhaitez ou de recréer la table.
https://wiki.postgresql.org/wiki/Alter_column_position

Cordialement,

Arkhena

#20 Re : PL/pgSQL » import de plusieurs tables » 20/02/2017 09:55:42

Bonjour,

Vous pouvez aussi créer vos requêtes d'insertion sous Excel en utilisant la fonction de concaténation et en copiant vers le bas sur toutes les lignes.

Cordialement,

Arkhena

#21 Re : PSQL » psql/problème mot de passe » 20/02/2017 09:52:27

Bonjour,

Vous pouvez créer l'utilisateur Jean-Louis avec l'utilitaire createuser.

Cordialement,

Arkhena

#22 Re : Général » [résolu] Démarrage service postgres impossible » 17/02/2017 12:11:23

Bonjour,

Qui est propriétaire du répertoire /data/pgsql/donnees?
Quel user utilisez-vous pour démarrer le serveur ?

Cordialement,

Arkhena

#23 Re : Installation » Installation/ Désinstallation message d'erreur » 14/02/2017 16:22:11

Bonjour,

Je pense qu'il manque quelques infos pour pouvoir vous aider...

Êtes-vous sous Windows ou sous Linux ?
Avez-vous un processus postgres qui tourne ?
Que contient votre fichier pg_hba.conf ?

A priori, étant donné que vous travaillez en local, la modification de listen_adress à * ne sert à rien.

Cordialement,

Arkhena

#24 Re : Général » (Re)trouver la signature d'une fonction » 19/05/2010 15:54:09

C'est pour ça que j'utilise proargtypes  qui correspond à la signature... :-)

Je dois juste dropper une cinquantaine de fonctions sur une soixante-dizaine de schémas... J'aurai voulu générer mon script par un programme...

#25 Général » (Re)trouver la signature d'une fonction » 19/05/2010 13:40:49

Arkhena
Réponses : 3

Bonjour,

Afin de dropper une fonction, je dois connaître sa signature exacte.
Grâce à la table pg_proc, je récupère les données concernant la fonction. Malheureusement le champ proargtypes comporte des oids de type et je n'arrive pas à récupérer en une seule requête les types qui correspondent...

Comme un exemple est plus parlant qu'un long diecours, voilà ce que j'ai :

proargtypes : "1043 1043 1043 1043 23 1043 23"

Si je fais la requête suivante :
SELECT p.oid,p.proname, n.nspname, t.typname, n2.nspname, p.proisagg
FROM pg_proc p INNER JOIN pg_namespace n ON p.pronamespace = n.oid
               LEFT JOIN (pg_type t INNER JOIN pg_namespace n2 ON t.typnamespace = n2.oid
                         ) ON t.oid = ANY (p.proargtypes)
WHERE n.nspname = 'mon_schema'
    AND p.proname = 'mafonction'
ORDER BY n.nspname, p.proname, p.oid, t.typname

Il ne me sort que 2 lignes : Une pour le type 1043 et une autre pour le type 23.

Or, j'aurai voulu qu'il me sorte 7 lignes :
- 4 pour le type 1043
- 1 pour le type 23
- 1 pour le type 1043
- 1 pour le type 23

(Et dans l'ordre aussi tant qu'à faire...)
(Si je récupère les données en colonnes ou en chaîne de caractères, ça me va aussi)

C'est possible ou pas ?

Cordialement,

Arkhena

Pied de page des forums

Propulsé par FluxBB