Vous n'êtes pas identifié(e).
S'il s'agit d'une réplication complète je vous conseillerais d'ailleurs fortement d'utiliser la réplication interne de Postgresql qui est très efficace et très simple à mettre en place.
Comme le disait Guillaume, il faut s'assurer que le log_min_message ou le client_min_messages soit à notice.
Sinon dans pgAdmin, les raise s'affichent dans l'onglet "Messages" et non pas dans l'onglet "Sortie de données".
Mais ensuite, je me suis souvenu que vers la toute fin de l'installation de PostgreSQL sur ce serveur, j'ai eu une erreur ;"le lancement post-installation n'a pas pu être réalisé, l'installation est peut être incomplete". J'ai essayer de réinstaller le logiciel, mais la même erreur s'est produite.
L'erreur "le lancement post-installation n'a pas pu être réalisé" est souvent lié aux droits de lecture/écriture sur le répertoire DATA de votre installation postgresql. Assurez-vous que les droits ntfs sont corrects avec l'utilisateur postgres avant de réinstaller la base de donnée.
FOR i IN REVERSE 3..1 LOOP
NOTICE RAISE 'valeur de i : %', i;
END LOOP; -- Fin de la boucle FOREND;
$$ LANGUAGE plpgsql;SELECT p_boucleFor();
Rien ne s'affiche sous Query, pourquoi ?
Il faut faire un RAISE NOTICE et non un NOTICE RAISE
Juste en précision, ce sont les "wal" (write-ahead log) et non les wall. En cas de recherche ça vous simplifiera la vie 
Vous pouvez sinon écrire une requête du genre :
SELECT * FROM livre
JOIN (SELECT 'PUBLICITE' as lib UNION SELECT 'CINEMA' UNION SELECT 'PECHE') source ON libre."LIBELLE" like '%' || source.lib || '%'
même si cela reste peu pratique.
rjuju a écrit :Quelques options sont à modifier selon que la base de donnée est déjà créée ou non sur le serveur distant.
Le dump copiera les données de la base mais pas les informations de rôle de connexion.Merci rjuju. Si je comprend bien:
- j'ouvre psql
- je rentre la premiere commande pour copier ma base de donnée
- je rentre la seuxieme commande pour "l'enregistrer" sur le serveur.Par contre, j'aimerais justement savoir quels sont les options à modifier, puisque la base de donnée n'est pas encore crée sur le serveur?
Non, ce sont des exécutables windows, il faut donc les lancer en ligne de commande.
Pour les options, est-ce que le serveur est déjà installé ? oui a priori s'il y a un utilisateur postgres existant.
Pour les options différents, il faut rajouter un -C (sensible à la casse) pour dire de créer la base de donnée cible
la commande est donc
pg_dump -C -Fc -h votre_ip nom_de_la_base > sauvevegarde.backup
et le restore se fera comme ça :
pg_restore -h serveur_distant -f sauvegarde.backup -d postgres
l'aide est la : http://docs.postgresqlfr.org/9.0/app-pgdump.html et http://docs.postgresqlfr.org/9.0/app-pgrestore.html
1. Qu'est ce que je dois faire pour transferer ma base de donnée (définition de la base + données déjà presentes) de mon ordinateur
personnel vers le serveur distant, sans ecraser le mot de passe du compte postgres dejà installé sur le serveur distant? Quels fichiers
dois-je copier?
Il faut faire un dump de la base de donnée voulue, et la restaurer sur le serveur distant (via pg_dump et pg_restore et non directement par les fichiers du disque).
Les commandes seraient pg_dump -Fc -h votre_ip nom_de_la_base > sauvevegarde.backup
puis
pg_restore -h serveur_distant -f sauvegarde.backup -d nom_de_la_base
Quelques options sont à modifier selon que la base de donnée est déjà créée ou non sur le serveur distant.
Le dump copiera les données de la base mais pas les informations de rôle de connexion.
2. Quand j'ouvre l'executable de pdAdminIII situé sur le serveur distant à partir de mon ordinateur personnel, ce n'est pas les
données du serveur distant qui s'affichent (d'ailleurs, comme je l'ai dit, je n'ai encore rien créer dessus), mais plutôt celle du répertoire
postgreSQL de MON ordinateur personnel. Pourrais-je en savoir la cause?
La visualisation des données via pgAdmin n'est pas lié de la ou vous lancez l'exécutable, mais du serveur configuré. Je pense que vous avez une configuration du type postgres@votre_ip:5432. Pour voir les données du serveur distant, vous pouvez le faire depuis votre ordinateur personnel en ajoutant un second serveur et en mettant dans "hote" le dns ou l'ip du serveur distant.
Oui c'est cela, à part que ce n'est pas forcément la même database. Ca permet d'avoir des serveurs esclaves avec moins d'espace disque et de ne répliquer qu'une partie des données par exemple, ou d'avoir un serveur avec des disques plus rapides pour une table très fortement sollicitée ou ce genre de choses.
Cela permet également de ne répliquer qu'une seule database, ce qui n'est pas possible via la réplication intégrée à postgresql.
Slony permet également de la réplication sélective, sur un ou plusieurs serveurs ce qui peut parfois être intéressant.
En fait, ton installation n'a pas marchée (le initdb a échoué) et donc Postgresql ne peut pas se lancer.
Il faudrait que tu refasses une installation complète en vérifiant les droits sur le répertoire ou tu places le répertoire DATA si c'est la cause de l'erreur, ou alors faire un initdb à la main (http://docs.postgresqlfr.org/9.0/app-initdb.html) sur ce même répertoire.
Sinon l'erreur retournée dans l'observateur d’évènement s'il y a quelque chose pour postgresql.
A noter également que pgBouncer permet du pool de connexion sur 3 niveaux : à la requête, à la transaction et à la session (pgPool lui ne fait que du pool à la session je crois).
Bonjour à tous...
ici nous commençons à parler de PGPOOL et j'ai commencé a voir tout ça sur internet...
Sur ce que j'en ai lu, pouvez-vous me confirmer (ou pas !) mes interrogations suivantes :1°) C'est un produit qui optimise les temps de connexions
2°) Il répartit les connexions au mieux
3°) il les 'partage', dans le sens où il conserve une connexion existante pour la donner/l'associer à une nouvelle qui arrive...
4°) Est-ce vraiment un produit qui accélère les connexion (à peu près quel ratio ?)
5°) Existe t'il sur d'autre os que la Débian ?Merci pour vos réponses...
Bonjour
pgPool est un outil qui peut faire beaucoup de choses différentes, dont du pool du connexion et de la répartition de charges.
Il permet ainsi de gagner du temps en conservant une connexion ouverte, ce qui évite de passer du temps à en recréer une plus tard, ce qui est particulièrement efficace pour les bases de données qui ont beaucoup de connexions qui durent très peu de temps (frontal web par exemple).
Sinon, il peut tourner sur n'importe quel linux.
Pour le reste, je ne sais pas trop comment se passe la répartition de charge je ne m'avancerai donc pas.
Pour une sauvegarde complète d'une base de donnée que préconnisez- comme option et au plus simple ?
Si vous voulez sauvegarder uniquement une base de donnée, le pg_dump suffit, mais les objets globaux (roles de connexion, tablespaces etc) ne seront pas sauvegardés.
Vous pouvez utiliser un pg_dumpall -g pour sauvegarder les objets globaux en plus de cette sauvegarde de base.
Un pg_dumpall sauvegarde l'instance entière (toutes les bases + objets globaux) mais ne compresse pas les données et rend la sauvegarde très volumineuse.
Je viens de tester et la séquence fait son travail avant même le déclenchement du trigger BEFORE INSERT.
Si tu veux vraiment continuer sur ce principe, il te faut donc faire un trigger AFTER INSERT comme tu avais fait précédemment (qui se lancera alors même si la séquence a été utilisée), ou alors coder ton application de manière a ce que seule la séquence soit utilisée en INSERT, et gérer de façon propre tes UPDATE pour qu'il n'y ait pas de soucis.
ok merci gleu, une dernière question et je te laisse x)
Ce que je voudrais faire, c'est juste savoir dans ma procédure si l'utilisateur écrit
ça : INSERT INTO table1(id,nom) VALUES(2,'blabla1'); -- à ce moment là je devrai mettre à jour last_value
ou ça : INSERT INTO table1(nom) VALUES('blabla1'); -- le serial fait le travailCette procédure ressemblerai à ça :
CREATE OR REPLACE FUNCTION updateNextvalTable1() RETURNS TRIGGER AS $$ DECLARE val integer; BEGIN if(NEW.id > 0) then SELECT max(id) INTO val FROM table1; val = val + 1; EXECUTE 'ALTER SEQUENCE table1_id_seq RESTART WITH ' || val; end if; RETURN NEW; END; $$ language 'plpgsql'; CREATE TRIGGER TriggerUpdateNextvalTable1 AFTER INSERT ON table1 FOR EACH ROW EXECUTE PROCEDURE updateNextvalTable1();problème : mon if fonctionne dans tout les cas ! Donc last_value se mettra à jour alors qu'il est deja à jour si je tape mon insert sans precisé l'id !
Le probème vient que ton trigger se lance après l'insert, c'est-à-dire une fois que la séquence a fait son travail, et il est alors impossible de différencier les 2 utilisations. Peut-être qu'en faisant le trigger BEFORE INSERT tu peux différencier les 2 cas mais je n'ai jamais testé et je ne peux pas te répondre, même si j'aurais tendance à penser que le new.ID serait à NULL et non pas à 0. Peut-être que Guillaume aura une réponse sure.
En fait pas vraiment, j'ai pris conscience que "combler les trous" ne servait à rien, par contre ce qu'il m'arrive de faire assez souvent, c'est de modifier l'ordre des lignes. Exemple :
ligneA d'id 1
ligneB d'id 2
ligneC d'id 3Je veux mettre ligneB en dernière position, alors j'obtiendrai ça :
ligneA d'id 1
ligneC d'id 3
ligneB d'id 4 -- erreur lors du prochain insert car last_value n'est pas à jourPeut être me conseillera tu de mettre un champ "position integer" mais je trouve ça moins propre !
Effectivement mon premier réflexe serait de te conseiller un autre champ pour gérer la position, pour ne pas mélanger un identifiant de ligne avec une valeur fonctionnelle, ou éviter des problème de propagation de clé étrangères (ON UPDATE CASCADE). A tous hasard est-ce un choix d'ordre subjectif ou y aurait-il une autre zone sur laquelle tu pourrais exercer un tri (date, valeur ...) ?
Oui, c'est vrai que je n'ai pas répondu à la question désolé, mais sauf cas exceptionnel je pense qu'il est mieux de garder le fonctionnement de base des séquences et de toucher le moins possible aux champs liés, et c'est en ce sens que j'intervenais.
Effectivement lors d'une mise à jour de ce champ la séquence n'est pas mise à jour, mais c'est normal car un champ de type serial n'a pas vocation a être mis à jour. Est-ce dans un soucis de "combler les trous" que tu veux faire un update du champ id ? Car comme le disait Marc vu le nombre de valeur possibles ce n'est vraiment pas nécessaire.
Vraiment laisser la séquence gérer toute seule ce champ est la solution la plus simple et la plus sûre.
Si au pire des cas tu ne dois avoir aucun trou dans la séquence, je te conseillerai plutôt des opérations de maintenance planifiées en dehors de la production pour la remettre à niveau.
Si le serveur est spécifié par un dns, je crois que le fichier pgpass est sensible à la casse donc cela peut provenir de la.
Sinon il est également possible de spécifier la connexion en "trust" dans le pg_hba.conf si vous avez accès au serveur, et le mot de passe ne devrait plus être demandé. Mais ce n'est pas forcément la meilleure solution, en cas de distribution pour des clients par exemple.
