Merci pour la réponse, mais j'ai trouvé une methode pour au moins connaitre toutes les fonctions qui accedent à une table.
Toutes les fonctions sont stockées dans la table "routines" du catalogue, il suffit ensuite de faire un select pour extraire toute celles qui utilisent une table précise.

Exemple avec la table "lot"  et comme chaque colonne de chaque table à un préfixe unique alors je peux aussi les récupèrer

select routine_name, routine_definition  from information_schema.routines
   where specific_schema = 'public'   and
     routine_definition like '%lot%';

Nouveau problème avec Notify

J'ai placé la commande Notify dans un trigger pour chaque Insert/Update d'une certaine table.
Lors de la mise à jour d'UN record, je recois bien de facon synchrone le message de notification dans mon application, un service windows qui tourne sur la meme machine que la base postgresql donc pas de problème lié au réseau du genre Time_out, l'execution coté service a été réduite au minimum, c'est à dire juste enregister un trace dans un fichier.

Lors de la mise à jour de 3 records (voire plus) je recois  UN message de notification en mode synchrone les 2 autres en mode asynchrone !
Pour une investigation plus simple je place depuis l'editeur SQL de pgAdmin les commandes suivantes.
select pg_notify('modif_table', '101');
select pg_notify('modif_table', '102');
select pg_notify('modif_table', '103');     je lance l'execution,   coté application  je recois   101 uniquement

Maintenant je place ces 3 autres commandes
select pg_notify('modif_table', '201');
select pg_notify('modif_table', '202');
select pg_notify('modif_table', '203');      je lance l'execution.... et je recois   102, 103, 201 !

Maintenant je place ces 3 autres commandes
select pg_notify('modif_table', '301');
select pg_notify('modif_table', '302');
select pg_notify('modif_table', '303');     je lance l'execution.... et je recois   202, 203, 301 !    etc...

J'ai essayé de placer des pg_sleep() de 1s de 5 s...  entre chaque commande, juste à la fin...etc sans un meilleur résultat.

Autre information : Version de la base 9.0.3,  de pgAdmin 1.12.2

Y aurait-il une solution ?  Est-ce un bug ?
Merci
Philippe

Je viens de supprimer ce process, et l'afficheur de performance de windows à diminuer d'autant la mémoire consommée.

Pour avoir une réponse synchrone il suffit d'ajouter cette ligne dans la chaine de connexion
   SyncNotification=true
Voir ce lien    de Francisco Figueiredo Jr    http://fxjr.blogspot.com/2006/04/synchr … ained.html

Thursday, April 13, 2006
Synchronous notification explained

Hi all,

it seems that my coined feature name "synchronous notification" is confusing everybody. I hope to explain it better now.
.....
It is disabled by default. You can enable it by specifying SyncNotification=true in your connection string.

Note: En version 8.4  les fichiers log sont en ascii

Meme avec  lc_messages = 'fr_FR.UTF-8'   les logs restent en asccii

J'ai activé les traces de npgsql  ( NpgsqlEventLog.Level = LogLevel.Debug;) et l'on peut voir que le blocage se trouve dans la classe  NpgsqlStartupPacket,
     WriteToStream_Ver_3(Stream output_stream) 
       {
       PGUtil.WriteInt32(output_stream, 4 +4 +5...)

       ....
       output_stream.Flush();    c'est cette instruction qui se bloque durant 15..20s
       }

Pusique c'est un flush, on peut l'utiliser apres chaque PGUtil.Write... et observer les resultats.
En fait si on place un flush sous le 1er write de cette fonction, celui-ci se bloque mais pas les suivants.
En observant les datagrams sur le réseau on voit que le 1er flush ne se contente pas d'ecricre quelques octets, et je suppose que cela correspond à l'échange des clés pour la mise en oeuvre du SLL.