Vous n'êtes pas identifié(e).
Pourquoi réinitialiser ?
Votre séquence ne sert-elle pas qu'à assurer l'unicité de votre clé primaire ?
tout se passe bien si les variables d'environnement sont correctement configurées.
Bonjour,
Je plussoie.
Cordialement,
Arkhena
Bonjour,
Il va vous falloir utiiser du SQL dynamic pour faire ça:
https://www.postgresql.org/docs/9.5/sta … namic.html
Cordialement,
Arkhena
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...
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
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!!!
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
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
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
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
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
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
Bonjour,
Il y a peut-être un point-virgule de trop en fin de ligne ?
Cordialement,
Arkhena
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...
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
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
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
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
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
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
Bonjour,
Vous pouvez créer l'utilisateur Jean-Louis avec l'utilitaire createuser.
Cordialement,
Arkhena
Bonjour,
Qui est propriétaire du répertoire /data/pgsql/donnees?
Quel user utilisez-vous pour démarrer le serveur ?
Cordialement,
Arkhena
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
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...
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
