C'est pas gentil de se moquer ;-)
Pour ceux qui, comme moi, n'osent pas toucher à un système en production, je me suis donc jeté à l'eau.

Mon SGBD est sur une distribution CentOS (un RedHat like). J'y ai installé un RPM mettant la liste des sources yum à jour (rpm -ivh pgdg-centos-8.3-6.noarch.rpm), puis j'ai juste fait un "yum update postgresql". Le système a automatiquement chargé les nouveaux binaires, résolu les dépendances, et redémarré PostgreSQL. Je n'ai même pas réussi à mesurer le temps d'indisponibilité (marginal dans mon cas). Et tout marche!!!

PS: En ce qui concerne la requête soumise en début de ce thread, le gain d'exécution est négligeable. Mais je ne regrette pas pour autant d'avoir effectué cette opération.

Encore merci pour tout,

Jérôme

Il semblerait que, décidément, mes exemples sont tous mauvais. Je ne connais du "RAC" d'Oracle que la brochure commerciale et je ne souhaite pas que PostgreSQL copie telle ou telle base, mais qu'il s'améliore encore et encore. N'est-il de toutes façons pas déjà le meilleur SGBD ;-) ?

Honnêtement, je ne plains absolument pas de la disponibilité de PostgreSQL, même en version "mono-serveur". En 7 ans, sur un système gérant plusieurs millions de requêtes par jour, je n'ai eu qu'un seul plantage, qui était dû à un défaut sur une carte mère. Difficile de faire mieux en terme de disponibilité !

Néanmoins, j'aimerais pouvoir "facilement" basculer sur un 2ème serveur, le temps par exemple d'upgrader mon serveur principal en 8.4, sans pour autant interrompre le service. En effet, si l'installation des binaires est relativement rapide, remonter un dump demande beaucoup de temps (je n'ai pas testé en 8.4 qui, d'après ce que j'ai compris, améliore ces performances en parallélisant les requêtes, mais jusqu'ici, cette opération nécessitait plusieurs heures).

En fait, ma principale réflexion concerne la répartition de charge. Non pas que les performances de PostgreSQL soient mauvaises, loin de là, mais ses nouvelles fonctionnalités, notamment T-search, m'ont ouvert la voie à de nombreux développements complémentaires. Là où j'utilisais autrefois PostgreSQL comme un simple entrepôt de données, il devient aujourd'hui une "brique" offrant des services de plus en plus riches. Or, dans ce cas, la montée en charge commence à devenir problématique. J'ai par exemple une table sur laquelle je fais des recherches T-search. Elle contient environ 4 millions de lignes et, bien que le 'tsvector' y soit renseigné et indexé, une recherche dure quelques secondes. Ce n'est pas un problème quand un utilisateur lance une requête, mais ça le devient quand j'en ai 5000 simultanés. Je cherche donc un moyen de répartir la charge (je peux rajouter plusieurs serveurs si nécessaires), sans pour autant trop me compliquer la vie, sachant que les développements s'intensifient, et que, par conséquence, les évolutions du schéma sont relativement fréquentes.

Voilà, vous savez tout sur mes besoins actuels; ceci éclairera peut-être sous un angle différent mes précédents posts.

En tout cas, merci pour votre attention et vos précieux conseils.

Jérôme

Je vois que je ne suis pas le seul à m'intéresser à ces problèmes de réplication.
Je m'associe à Zied en trouvant que les outils de réplication sous PostgreSQL restent relativement mal intégrés (configuration "lourde", maintenance rendue pénible à cause de la non synchronisation des schémas,...) et, de mon point de vue, "risquées".
Ce que j'entends par là, c'est qu'on peut mettre en place une réplication qui va fonctionner de façon fiable et performante à un instant t, mais qui pourra être "cassée" par inadvertance, parce que quelqu'un aura modifié un schéma sans penser à
1) modifier les esclaves et
2) ajouter/modifier la règle de synchronisation.

De ce point de vue, il faut bien reconnaitre que "l'autre base libre" a une approche mieux intégrée de point de vue de l'utilisateur.

Votre article sur Londiste m'a donné des idées à ce sujet. Vous expliquez comment recopier le schéma de la base maitre vers la base esclave (je n'ai pas l'article sous les yeux, mais je me souviens que le principe global s'appuie sur pg_dump -s). En sauvegardant le résultat dans un fichier d'une fois sur l'autre, il est facile de détecter tout changement de schéma. En cas d'ajout de tables, si ma mémoire est bonne, on peut rappeler la commande de réplication pour toutes les tables. Dans ce cas, si j'ai bien compris, l'outil va ignorer cette requête pour les tables déjà répliquées. Le tour est donc joué, simplement !
Mais, bien entendu, un changement de schéma ne se résume pas à un ajout de tables. Et pour tous les autres cas, je n'ai pas vraiment d'idées.

Je connaissais ce post sur unaccent; nous en avions parlé dans un précédent thread ;-)

Quant à l'astuce qui consiste à créer l'index sur une version sans accent du texte, c'est ce que je fais actuellement.
Dans la réalité, pour des pages assez lourdes, le post-traitement nécessaire pour obtenir un affichage avec accents est cependant inutilement lourd (il peut y avoir plusieurs occurrences du terme recherché...)

Enfin, en ce qui concerne l'astuce pour gérer les traits d'union, je regrette parfois que l'approche -par ailleurs puissantissime de PostgreSQL- occulte quelques cas pourtant bien pratiques; par exemple:

-la recherche d'une expression, habituellement associée aux guillemets, n'existe pas (à ma connaissance du moins). Si l'on reprend l'astuce utilisée pour faire ressortir Saint-Pierre, on risque aussi de faire ressortir Saint-Marc, Saint-Paul,... D'une manière générale, je n'ai pas trouvé comment faire une recherche exacte. Un exemple; sur docs.postgresql.fr, si je recherche "postgresql version 8.4", je retrouve entre autres "versions de PostgreSQL™ antérieures à la 8.4". Un moteur de recherche reconnaissant les guillemets n'échouerait pas sur ce point

-la recherche étendue est une des forces de Tsearch, mais elle génère parfois un bruit inutile. Il serait confortable que l'on puisse là aussi forcer une recherche exacte. Par exemple, sur docs.postgresql.fr, si je recherche window (afin d'explorer les nouveautés de la version 8.4, bien sûr), il est dommage de trouver parmi les réponses des articles traitant de Windows.

Il se trouve que la plupart de mes besoins traitent de lieux. Tant que le nom du lieu tient en un mot, cela ne pose pas de problèmes, mais dès que l'on a des noms de lieux composés (tous les Saint-XXX, mais aussi les noms avec sur-sous-le-la-... posent beaucoup de problèmes. La plupart des moteurs de recherche (moteurs Web, Google, Bing,... où intégrés à des produits divers), permettent facilement de contourner ce problème, et de trouver les documents souhaités. Je suis frappé par les innovations réelles et pertinentes qu'apporte PostgreSQL à ce niveau (recherche par racine de mot, dictionnaires de synonymes, thésaurus,...) et, dans le même temps, par le fait qu'il n'apporte pas de réponse à certains critères qui me semblent pourtant assez basiques.

Merci !

Je suis un peu honteux, j'aurai quand-même pu trouver ces liens sans trop d'effort...
Ceci dit, si c'est une notion particulièrement puissante, ce n'est pas si trivial que ça à mettre en œuvre.

Oui, pas de problème à ce niveau là.
D'ailleurs, s'il ne la trouve pas (j'ai fait différents essais), on n'obtient pas le même comportement. En effet, dans ce cas là, on a un erreur dès qu'on essaye de créer la fonction. je n'ai plus le message précis en tête, mais il est du style "unable to load libunac.so"

Bonjour,

Et merci d'avoir pris le temps de s'intéresser à ma demande.

L'erreur apparaissant dans /var/log/message est la suivante:
kernel: postmaster[8680]: segfault at 0000000000000000 rip 00002aaaab3ffd80 rsp 00007fff1a823048 error 4

PS: c'était moi, l'interlocuteur qui évoquait le sujet à Solutions Linux

Grâce au message de Marc Cousin, j'ai réussi à compiler l'ensemble sans erreur.
Malheureusement, j'ai malgré tout toujours un segfault :-((

Merci quand-même pour votre aide.

Merci pour ta réponse, mais cela me gêne un peu. En effet, le problème ne vient pas a priori de PostgreSQL lui-même, mais plutôt de la compilation des 2 librairies tierces. D'ailleurs, ça ne pose visiblement pas de problème sous Debian, qui propose déjà libunac1 dans ses dépôts.