Ces requêtes n'ont pas l'air d'avoir un rapport avec des INSERTs. Il est normal d'avoir plein de verrous dans une base active, tant qu'ils ne sont pas pris indéfiniment.

Il faudrait commencer par

select * from pg_stat_activity;

pour avoir une vue d'ensemble des sessions en cours.

A part ça, si les 10000 INSERTs sont réellement simultanés, c'est excessif. Très schématiquement, diviser ça par le nombre de threads effectifs des CPUs du serveur et ça donne une idée du ratio de surcharge.

Le client doit positionner en fonction du serveur auquel il veut se connecter,
soit les variables d'environnement PGSSL* mentionnées ici:

https://www.postgresql.org/docs/current … nvars.html

soit les options de connexion équivalentes sslcert / sslkey / sslrootcert / sslcrl dans la chaine de connexion.

Oui effectivement Guillaume,dire que le CTID ne change pas dans une transaction c'est tellement un raccourci que c'est faux. En particulier en READ COMMITTED.

Mais dans le cas du trigger mentionné ici, je ne pense pas qu'il soit possible que OLD.ctid désigne une autre ligne que celle pour laquelle le trigger a été déclenché. Je ne pense pas non plus que cette ligne puisse disparaitre à ce moment car elle est verrouillée. Au pire l'UPDATE n'arriverait pas à l'atteindre si elle n'est plus visible.

Oui dans les versions récentes de postgres en tout cas, il est possible d'insérer directement dans une vue, lorsque la requête de la vue est un simple filtre mono-table. Quand c'est plus compliqué il faut faire des triggers INSTEAD OF dont le code embarque l'intelligence de comment les mises à jours de vues doivent remonter dans les tables.

Exemple sur une instance 9.5:

test=# create table la_table(champ text, actif bool default true);
CREATE TABLE

test=# insert into la_table(champ) values('foo');
INSERT 0 1

test=# create view la_vue as select champ from la_table where actif=true;
CREATE VIEW

test=# insert into la_vue(champ) values('bar');
INSERT 0 1

test=# select * from la_table;
 champ | actif 
-------+-------
 foo   | t
 bar   | t
(2 rows)

test=# select * from la_vue;
 champ 
-------
 foo
 bar
(2 rows)

test=# delete from la_vue where champ='foo';
DELETE 1

test=# select * from la_vue;
 champ 
-------
 bar

Je ne sais pas. Ca fait bien longtemps que je n'ai plus utilisé Access pour ma part, et je ne me souviens pas exactement de ce qu'il faisait avec l'intégrité référentielle sur des tables liées en ODBC. C'est dans l'éditeur de requêtes qu'il pré-positionne automatiquement les liens entre PK et FK? J'imagine qu'on peut s'en passer. L'intégrité référentielle sur les écritures sera contrôlée par postgres de toute manière.

Je vais répondre dans l'autre discussion pour l'écriture du SQL dynamique dans les triggers.

La manière la plus simple est d'utiliser \set pour construire une nouvelle variable, car \set va concaténer les éléments sans séparateur.
Attention il n'y a aucun signe "égal" à mettre entre la variable et l'expression, sinon il va le prendre comme faisant partie de l'expression.

Exemple:

test=> \set app agu
test=> \set rolename r_ :app _dba
test=> \echo :rolename
r_agu_dba
test=> create role :"rolename";
CREATE ROLE
test=> select rolname from pg_roles order by oid desc limit 1;
  rolname  
-----------
 r_agu_dba
(1 row)

Les commandes du genre createuser ou psql prennent un argument -U où l'on peut spécifier un utilisateur.
En mettant -U postgres il n'utilisera pas "Jean-Louis" mais postgres, qui est le super-utilisateur que l'installation
a dû créer.
Si de plus pg_hba.conf a été changé dans ce sens il ne demandera pas de mot passe.

Dans le cas de createuser le -U ne désigne pas l'utilisateur à créer mais bien d'un utilisateur existant
avec lequel se connecter pour pouvoir en créer un autre. Il est impossible de créer un nouvel
utilisateur si on n'a pas déjà la faculté de se connecter avec un utilisateur existant, et qui plus est,
qui a le droit d'en créer d'autres.

Ceci dit pour ma part je ne comprends pas ce que sont: les prompts "prêts à l'emploi"
Quand j'installe pg9.6 sur Windows 8.1 téléchargé de entreprisedb, je ne vois rien à cliquer nulle part
une fois l'install terminée. J'ouvre une invite de commandes cmd.exe, puis dedans
cd c:\Program Files\PostgreSQL\9.6\bin et je lance les commandes à la main à partir de là.
Evidemment Il est aussi possible d'ajouter ce répertoire à son PATH pour les lancer de n'importe où.

Autant faire directement

 IF not exists (select 1 from public."tblContacts" where audit_id = r.audit_id) THEN
   ...

Ca économise une instruction et une variable et ça marchera dans tous les cas de figure.

1/ Comment se fait il que je n'ai pas vu d'autres erreurs de ce type alors que de nombreuses fonctions stockées sont définies avec des paramètres déclarés en int4, et appelées avec des long en paramètre ?

Les éléments de réponse sont à trouver dans l'API / la bibliothèque C++ utilisée côté client pour s'interfacer avec le serveur. Certaines APIs vont injecter les paramètres textuellement dans la requête sans indication de type, auquel cas c'est le serveur qui déduit le type et le problème en question ne se produira pas. D'autres vont déduire le type SQL du type C++, en l'occurrence "long" si 8 octets correspond à [select oid from pg_type where typname='int8'] donc le type d'OID 20. Si la lib C++ utilise en sous-main PQexecParams() de libpq et met en dur 20 dans le tableau paramTypes, alors le serveur SQL se basera dessus et ça produira l'erreur en question s'il n'y pas de fonction acceptant bigint. La même différence peut se produire selon que les APIs clientes utilisent les prepared statements ou pas. Dans certains cas il y a un switch logiciel qui permet d'activer ou non les prepared statements parce que ça a des effets sur les performances par ailleurs, et parce que les paramètres ne peuvent pas être utilisés librement dans les requêtes DDL.

2/ Pourquoi cette différence de comportement entre une version 8.4 et une version 9.5 ? (je n'ai rien vu dans les release notes)
Un large changement de cast implicit a lieu en 8.3 mais pas après, et ça concernait surtout le sens texte->entier.
Voir http://petereisentraut.blogspot.fr/2008 … resql.html

3/ Existe-t-il une façon de forcer un cast pour ce type de paramètres ?
On peut créer des CAST implicites avec CREATE CAST mais dans le cas int8->int4, ça parait une mauvaise solution puisque la majorité des valeurs de la source ne pourraient pas être converties dans la destination.

Pour moi le plus logique serait de faire l'inverse, passer le paramètre de la fonction de int en bigint puisque la taille de ce paramètre est 64-bit côté client, et  "qui peut le plus peut le moins".

Il est aussi possible d'avoir deux versions de la même fonction, une prenant int, l'autre bigint. Mais elles doivent renvoyer le même type.

Comme alternative au SQL dynamique, il est aussi possible d'utiliser la fonction pg_notify().

D'après la doc:

D'ailleurs pas besoin de mettre current_schema() dans une variable en plpgsql, mais en revanche il faudra utiliser PERFORM en procédural plutôt que SELECT puisque cette fonction ne renvoie rien.

BEGIN
   PERFORM pg_notify(current_schema() || '_GIService', '-');
   RETURN NEW;
END

Le schéma DE_17 n'est pas exclu du dump malgré l'option -N 'DE_*' parce que les règles de mise en minuscule du SQL s'appliquent sur cette option.

La doc de pg_dump ramène à celle de psql au sujet de ces "motifs", et cette dernière doc dit:

http://docs.postgresqlfr.org/9.6/app-psql.html

Donc pour exclure ces schémas en majuscules, il faudrait ajouter des guillemets autour de la partie fixe du motif, soit

pg_dump -N '"DE_"*'  [...autres options]...

Pour la partie historique, la debian 6 (etch) était associée à postgresql 8.1
C'est la debian 3 (woody) qui avait postgresql 7.2

En fait, on vous demande de faire tourner sur une debian obsolète un postgresql encore plus obsolète.

En revanche Perl 5.14 c'est vraiment récent par rapport au reste.
Mais concernant ça, ce n'est pas forcément Perl lui-même qu'il faut regarder, c'est DBD-Pg,
voir notamment ça:
http://search.cpan.org/dist/DBD-Pg/Pg.pm#prepare

Les prepared statements via le protocole n'existaient pas avant le protocole 3.

Donc quand on est en protocole 2 (avec postgresql 7.2) logiquement il faudrait les inhiber.
C'est faisable avec

  $dbh = DBI->connect($DBNAME, $DBUSER, $DBPASS,
                      { AutoCommit => 0,
                        RaiseError => 1,
                        pg_server_prepare => 0,
                      });

Je ne sais pas si c'est suffisant (j'en doute) mais je pense que c'est nécessaire. dans votre configuration.

Sinon, compiler un DBD::Pg qui date de 2007 (=2002+5 ans) mais pas après, en espérant qu'un vieux DBD-Pg soit compilable avec un nouveau Perl, ce qui n'est pas non plus garanti.

Quel est le type de la colonne name? text/varchar(N) ou bytea?

Quel est son contenu brut?

Quel est l'encodage serveur et l'encodage client (show server_encoding; et show client_encoding; )

Ces questions car le cast de TEXT en BYTEA produit un résultat qui dépend de l'encodage.

Exemple en base UTF-8:

=> select 'é'::bytea;
bytea 
--------
\xc3a9

En base LATIN9:

=> select 'é'::bytea;
bytea
-------
\xe9

A ce propos quelque chose qui pique les yeux est que é est un E accentué encodé en UTF-8 mais interprété en ISO. Ca arrive soit quand le client_encoding n'est pas bon, soit parce que le contenu a été doublement converti LATIN1->UTF-8 puis encore LATIN1->UTF-8, la deuxième passe corrompant le contenu.

Ca n'explique pas le résultat montré dans la question, mais ça laisse penser que le contenu de la colonne est mal encodé dès le départ.

Quand on applique digest() à un texte, l'encodage des caractères compte aussi. Le même texte ne donnera pas le même digest dans un encodage ou un autre, car l'algorithme de digest s'applique aux octets, par aux caractères.

UTF-8:

=> select digest('é', 'SHA1');
                   digest                   
--------------------------------------------
\xbf15be717ac1b080b4f1c456692825891ff5073d

LATIN9:

=> select digest('é', 'SHA1');
                   digest                   
--------------------------------------------
  \x1599e9fa41ec68c80230491902786bee889f5bcb