J'ai bien modifié sysctl.conf et redémarré à chaque fois.
J'aurais pu mettre plus de shared buffer, mais je que je comprend pas pourquoi si on fixe
shmmax= 2^28 = 268 435 456 soit 268,435 456 millions, et un shared_buffer=268MB alors postgres râle,
alors qu'il ne râle plus avec 200MB.
J'ai l'impression que l'erreur vient du fait de l'approximation que je fais en considérant que 1Mo = 1 000 000 octets != 2^20 = 1 048 576
Si on fait le calcul juste avec shmmax=2^28 on a
shared_buffer = 2^28/2^20 = 2^8 = 256MB
C'est exactement la valeur que donne rjuju
pourtant il râlait avec shared_buffer=250Mo autant et de la même manière qu'avec shared_buffer=268Mo

Finalement, j'ai une solution pour m'en tirer avec shared_buffer=200Mo et j'aimerais comprendre.
Au fait, je suis avec postgres 9.2 et ubuntu precise, mais je ne crois pas que cette info soit très utile.

Je viens de faire un nouveau test en reprenant les valeurs de rjuju:

shmmax=512MB

et

kernel.shmmax=536870912
# 2^29
kernel.shmall=131072

postgres me donne l'erreur:
DETAIL:  Failed system call was shmget(key=5432001, size=572530688, 03600).
il va chercher une mémoire dont la taille est 572530688 est supérieure (de peu) à 2^29
si on change shared_buffer à 500, on a l'erreur:
DETAIL:  Failed system call was shmget(key=5432001, size=558759936, 03600).
si on change shared_buffer à 490 on a l'erreur:
DETAIL:  Failed system call was shmget(key=5432001, size=547717120, 03600).
si on change shared_buffer à 450 on n'a plus l'erreur!
BYZARRE non?

J'ai proposé l'extension à Prague PGConf.EU 2012 comme l'as suggéré Guillaume, mais la proposition n'a pas été acceptée.
L'extension qui fait maintenant l'usage de requêtes récursives - c'est vraiement pratique - a été portée sans problème sur postgreSql 9.2.
Je ne sais vraiement pas m'y prendre avec les questions de communication.
Voilà un exemple: http://olivierch.github.com/openBarter/
Si vous avez des suggestions, elles sont bienvenues.

Bonjour Damien et Jean Paul,
Merci pour ces encouragements.
Auriez vous connaissance de la manière de s'y prendre pour proposer une présentation au fosdem sur le sujet?
___________________________
Olivier Chaussavoine

DIJXSTRA qui est un pionnier de la théorie de graphes, a été le premier à publier en 1965 un court article sur le sujet:
http://www.dis.uniroma1.it/~baldoni/p569-dijkstra.pdf
Bien d'autres ont ensuite fait référence au problème de fond qu'il a soulevé.

Bonjour Cédric,

L'extension est portée sur la version 9.1 .  Je vais prendre connaissance de CREATE EXTENSION, et suivre tes recommandations.

Merci pour ces conseils.

J'aurais bien aimé pouvoir le faire avec postgres, mais je n'ai pas une connaissance suffisante de ses mécanismes internes pour faire ce que j'ai pu réaliser avec berkeleyDb. Ce sont des tables temporaires dont la durée de vie se limite à la requête postgres, qui me permettent de parcourir très rapidement le graphe des offres, et appliquer plusieurs algo de recherche. Toutes les tables berkeleydb restent en mémoire vive, et n'ont aucun mécanisme de sémaphore, ce qui permet d'éviter les problèmes de verouillage cyclique qu'on rencontre souvent lors de parcours de graphe. Lorsque les résultats sont rapatriés, les données sont versionnées, et rejetées si elles ne sont pas à jour. Je ne crois pas que ça doit arriver trop souvent.
Avantages du choix - ça marche. Inconvénients majeur - je dois allouer environ 4Mo par client séparément de la gestion mémoire de postgres. Je fais en sorte que ce quota ne soit jamais dépassé.
Il y a certainement moyen de faire la même chose en postgres, mais je ne m'y connais pas assez. Une partir de mon code pourrait en tout cas être repris car l'interface se limite à deux fichiers: 1) l'initialisation de la structure des tables 2) un ensemble d'itérateurs sur ces tables. Les tables contiennent des structures C propres à l'appli. Rien d'autre est dépendant de berkeleydb.