Attention : agir de la sorte signifie que vous allez "tromper" l'application et les utilisateurs. Ainsi un utilisateur de la base lancera un INSERT, qui sera remplacé à la volée par une UPDATE sans que celui-ci en soit informé. C'est pas très propre et ça peut conduire à de très grosses incompréhensions.

D'un point de vue logique, c'est plutot l'application qui doit "prendre la décision" de faire un INSERT ou un UPDATE.... Par exemple, le fait que l'appli tenter d'insérer un ligne qui est déjà dans la base c'est une information en soit et ce n'est pas la même chose qu'une mise à jour d'une ligne. Pourtant avec ce que vous proposer, les deux opérations auront le même résultat.

Par ailleurs, une fonction telle que vous l'écrivez ci-dessus aura un impact négatif sur vos perf en écriture.

Malgré tout, si vous voulez vraiment faire ce genre de ré-écriture à la volée alors les règles (RULES) sont faites pour vous :

http://docs.postgresql.fr/9.1/rules-privileges.html

Mais au risque d'être lourd, j'insiste une dernière fois : les subsitutions de requêtes à la volée sont un moyen simple et rapide de faire n'importe quoi avec vos données. :-)

Est-ce que le role pgbackup a été créé avec l'option INHERIT ?

c'est corrigé

Effectivemet si une transaction est lancée sur le serveur maitre initial cela influe sur le "nouveau" serveur maitre. Mais les deux bases seront dans un état incohérent et l'application aura potentiellement reçue une information erronnée.

Si on prend l'exemple d'un système de réservation de place de train .

- Le serveur A (maitre) distribue les places 1, 2, 3 et 4
- Le server A devient inaccessibble
- Le serveur B devient maitre
- Le serveur B distribue la place 5 et 6
- Le serveur A réapparait, reprend le traitement des requêtes en cours et distribue la place 5

Il y a donc conflit entre les deux bases. Ici l'exemple est simpliste et l'arbitrage est facile à faire mais on peut très rapidement se retrouver dans des conflits très durs à résoudre.

à un instant T, il ne doit y avoir 0 ou 1 maitre. C'est pour cela qu'il est essentiel de tuer le noeud inaccessible **avant** de basculer le noeud de secours.

Je viens de répondre par mail

Désolé pour le lag

Il n'y a pas de formule magique pour ce genre de situations. Essaie déjà de mesurer la quantité de ressources (CPU / RAM) dont les autres logiciels ont besoin....

ok ok ! Disons plutot 500€ ...

J'essaie juste de dire à  gom que s'il n' a plus de place sur son SAN alors il y a des priorités plus importantes que cette histoire de ré-indexation

La taille de votre index est probablement supérieur à l'espace disponible sur le tablespace... Vous pouvez connaitre facilement cette taille avec la commande :

SELECT pg_size_pretty(pg_relation_size(votre_index));

Je ne connais pas exactement le comportement de REINDEX mais il est probable que si vous voulez réindexer un index volumineux ( disons 3 Go ) . PostgreSQL va mettre un verrou en écriture sur l'index et en créer un nouveau  . Vous aurez donc besoin de 3Go d'espace libre puisque les deux index vont coexister sur le disque pendant la durée du REINDEX.

Je vois plusieurs solutions :

  a/ agrandir la partition 
  b/ placer l'index sur une partition avec assez d'espace libre
  c/ faire un DROP INDEX puis CREATE INDEX

A noter que stricto sensu, la solution c/ n'est pas équivalente à un REINDEX

http://docs.postgresql.fr/9.0/sql-reindex.html

Il faut déjà commencer par identifier de quel tablespace il s'agit :

Que donnent les requêtes suivantes :

select oid,* from pg_tablespace;
select spclocation from pg_tablespace where oid = 16395;

Je confirme : j'ai déjà eu ce problème. quand les logs ne sont pas en UTF-8, les accents font planter la fenêtre de statut.

Une solution intermédiaire : PGAdmin pourrait intercepter l'erreur et dans ce cas ne pas afficher la panneau de trace dans la fenêtre de statut....

Quelques liens quand même :

http://doxygen.postgresql.org/
http://wwwmaster.postgresql.org/redir/3 … 0.3.tar.gz
http://git.postgresql.org/gitweb?p=post … ;a=summary
http://www.postgresql.org/developer/coding