Vous n'êtes pas identifié(e).
Pages : 1
effectivement c'etait un probleme de quote !
je ne savais pas que c'etait une double quote.
Ca fonctionne, merci beaucoup Marc
J'avais essayé avec cette syntaxe mais ca ne marche pas.
Si j'écris :
CREATE SERVER writeshardedcluster FOREIGN DATA WRAPPER plproxy
OPTIONS (connection_lifetime '1800',
p0 'dbname=shard host=192.168.0.32 port=5435 options=-c search_path=affiliation_10',
p1 'dbname=shard host=192.168.0.63 port=5432 options=-c search_path=affiliation_0' );
Quand j'exécute ma fonction plproxy j'obtiens :
ERREUR: PL/Proxy function affiliation.get_clics(1): [(null)] PQconnectStart: option de connexion « search_path » invalide
Je me suis dis que c'etait peut etre un probleme de simple quote, mais je ne peut pas mettre de simple quote a l'interieur de la connexion string puisque la connection string elle meme doit etre entourée de simple quote.
Bonjour à tous,
Je suis actuellement en train de travailler sur du sharding et à ce titre j'utilise pl/proxy.
Tout se passe très bien cependant j'aurais aimé pour des raisons de simplicité et de scripting pouvoir multiplier les schemas plutot que les clusters sur un même serveur.
Dans la définition des foreign data wrapper, on ne peut pas aller plus en profondeur que la base de données lors de la creation des partitions (ex: dbname=shard host=192.168.0.32 port=5435)
J'aurais aimé pouvoir faire qque chose du style :
dbname=shard schema=shard_1 host=192.168.0.32 port=5435
dbname=shard schema=shard_2 host=192.168.0.32 port=5435
malheureusement pqconnect ne permet pas de spécifier un schema.
J'aimerais éviter de :
- multiplier les clusters
- multiplier les base de données
- devoir préfixer le schema à utiliser au niveau du code applicatif
Je me rends compte que j'ai une utilisation particulière des schemas, cependant quelqu'un a-t-il une idée afin de tout intégrer au niveau de pl/proxy ?
Merci d'avance
... qui n'est lui même qu'un pale echo de moi meme si ca te rassure 
Cependant je vous remercie tout deux pour votre rapidité 
Bonjour, je viens de trouver finalement.
Depuis la version 9.0, Postgresql intègre une instruction DO qui permet d'éxécuter un bloc de code et permet donc de scripter sans creer de fonctions.
http://www.postgresql.org/docs/9.1/static/sql-do.html
Dans mon cas ca donne quelque chose du style:
DO LANGUAGE plpgsql $$
BEGIN
IF NOT EXISTS(SELECT * FROM pg_namespace WHERE nspname = 'affiliation_0') THEN
CREATE SCHEMA affiliation_0 AUTHORIZATION postgres;
GRANT ALL ON SCHEMA affiliation_0 TO postgres;
END IF;
END$$;
Très pratique ce DO
Bonne journée tout le monde
Bonjour à tous,
pour un de mes projets, je souhaite pouvoir faire du scripting plpgsql mais sans passer par la création de fonction.
Est ce possible ?
Si ce n'est pas possible, existe-t-il une autre solution pour tester l'existence d'un schéma avant de le créer. (sans utiliser de fonction stockée)
En gros j'aimerais faire :
SI schema n'existe pas ALORS
CREER schema
FIN SI
En regénérant template1 à partir de template0, pg_upgrade se lance normalement ! Victory is mine
Merci pour votre aide et votre réactivité
Je parle de template1 car j'ai le meme mesage d'erreur quand j'essaye de m'y connecter que quand je lance la procédure pg_upgrade. D'où mon interrogation vis à vis de template1
Cependant, il est vrai que je ne vois pas vraiment le rapport entre pg_upgrade et template1.
Aujourdhui mon cluster 8.4 contient 2 bases user et les 2 bases systeme (template0 et template1). Recemment nous avons créé une base sans aucun probleme.
A noter que sur pgadmin, quand j'affiche les objets systeme, je prends toujours cette meme erreur quand j'essaye d'accéder à template1 de mon pg 8.4.
Alors que sur mon pg 9.1, j'accede normalement à tous les objets de cette base.
N'étant pas une base de données de production (et ne sachant pas quoi faire ), je vais essayer de recloner template1 a partir de template0. Je vous tiens au courant.
Bonjour, le parametre stats_temp_directory était bien le param par défaut (cad pg_stat_tmp)
Pour etre bien sur, j'ai décommenté la ligne dans postgresql.conf mais ce n'est toujours pas bon.
Savez vous si pg_upgrade travaille sur template1, ce qui pourrait etre la cause de ce bug ? Car pour ma base "normale" je n'ai pas d'erreur du tout et j'accede à tous les objets normalement.
Une solution pourrait etre de regénéré un template1 à partir du template0 ?
Je n'ai pourtant pas souvenir d'avoir "joué" avec template1
info peut etre utile :
je parviens à reproduire l'erreur en tentant de me connecter à template1 sur mon pg version 8.4 (psql template1 -p5432)
alors que je me connecte sans probleme sur mon pg version 9.1 (psql template1 -p5434)
Je ne suis pas à l'aise avec ce "template1" mais je suis tenté de dire que j'aurais un soucis de paramétrage sur ma bdd actuelle (8.4) ?
Bonjour,
je rencontre un probleme avec pg_upgrade que je ne parviens pas à corriger malgré mes nombreuses recherches sur Google.
Lorsque je lance la commande pg_upgrade avec les bons parametres voici ce qui se passe :
cmd : /usr/lib/postgresql/9.1/bin/pg_upgrade -u postgres -d 8.4/main/ -D 9.1/main/ -b /usr/lib/postgresql/8.4/bin/ -B /usr/lib/postgresql/9.1/bin/ -p 5432 -P 5434
dump :
Performing Consistency Checks
-----------------------------
Checking current, bin, and data directories ok
Checking cluster versions ok
connection to database failed: FATAL: ne peut pas accéder aux tables temporaires d'autres sessions
unable to connect to old postmaster started with the command: "/usr/lib/postgresql/8.4/bin/pg_ctl" -w -l "/dev/null" -D "/var/lib/postgresql/8.4/main" -o "-p 5432 -c autovacuum=off -c autovacuum_freeze_max_age=2000000000" start >> "/dev/null" 2>&1
Failure, exiting
A priori lorsqu'il essaye de démarrer l'ancien postmaster, il ne parvient pas à accéder aux bonnes tables temporaires, ca génère une erreur et derrière tout s'arrete.
Une idée ?
Pages : 1
