La première chose à faire, c'est de prendre connaissance des échanges que les développeurs PostgreSQL ont déjà eu sur ce sujet, pour évaluer la difficulté du problème. Il y a pas mal d'explications ici:
https://wiki.postgresql.org/wiki/Alter_column_position
(dont une bonne partie est "comment s'en passer", mais voir les liens à la fin de la page sur les discussions de "comment l'implémenter").

Il y a également cette discussion qui se réfère à un patch mais j'ai l'impression jamais envoyé (?):
https://www.postgresql.org/message-id/f … .gmail.com

Ca date de 2006-2007, mais il y a des chances que le problème principal posé par cette fonctionnalité soit le même aujourd'hui.
En version courte, le problème est qu'en interne Postgres se réfère à la position des colonnes dans la table en tant que clef primaire (attrelid, attnum), de telle manière que "décaler" ces positions remettrait en question un point de conception.
D'ailleurs une colonne supprimée garde son emplacement, elle n'est pas supprimée physiquement dans la couche de stockage.

La question qui se posera sur une remise en question de ce point de conception, c'est est-ce que ça vaut le coup? Les développeurs de Postgres font parfois des changements de conception importants, mais dans des cas où le retour sur investissement attendu est très significatif, comme par exemple le parallélisme intra-requête introduit par la version 9.6.

On peut vous donner tout de suite la réponse: ce lien entre utilisateur et verrouillage est une mauvaise direction.
Le verrouillage et les exclusions qui s'ensuivent s'entendent entre transactions.

Deux transactions concurrentes sont forcément dans des sessions différentes, mais qu'elles soient ouvertes par le même login ou pas n'a pas d'importance particulière par rapport à toutes les questions relatives aux verrous.

Un autre fait structurant important est que les verrous acquis dans une transaction sont libérés automatiquement à la fin de la transaction, et ne peuvent pas être libérés avant.

Une recherche rapide semble indiquer que "PEM" veut dire Postgres Enterprise Manager
dont l'installation est documentée ici
https://www.enterprisedb.com/fr/docs/en … ide-07.htm

D'après cette doc PEM contient de nombreux composants en plus de PostgreSQL. Par ailleurs
ça semble être un logiciel propriétaire avec une license d'essai de 60 jours.

Si vous voulez juste PostgreSQL sur Windows, n'installez pas PEM, mais plutôt ce qui est référencé à partir d'ici:

https://www.postgresql.org/download/windows/

L'exécution du script sous psql donne ça, pour la partie qui créé puis utilise des tables:

tst=> SET ROLE u1;
SET
tst=> CREATE TABLE s.test1(txt text);
CREATE TABLE
tst=> INSERT INTO s.test1 values('je suis u1');
INSERT 0 1
tst=> 
tst=> SET ROLE u2;
SET
tst=> SELECT * FROM s.test1;
    txt     
------------
 je suis u1
(1 row)

tst=> INSERT INTO s.test1 values('je suis u2 et je ne peux pas écrire dans test1');
ERROR:  permission denied for relation test1
tst=> 
tst=> SET ROLE u3;
SET
tst=> CREATE TABLE s.test3(txt text);
CREATE TABLE
tst=> INSERT INTO s.test3 values('je suis u3 avec ma table s.test3');
INSERT 0 1
tst=> 
tst=> SET ROLE u1;
SET
tst=> SELECT * FROM s.test1;
    txt     
------------
 je suis u1
(1 row)

tst=> SELECT * FROM s.test3;
               txt                
----------------------------------
 je suis u3 avec ma table s.test3
(1 row)

L'INSERT qui est rejeté pour cause de pas de permission montre justement que l'utilisateur u2 ne peut
pas écrire dans la table qui appartient à u1 (en revanche il peut la lire). C'est celui-là:

tst=> INSERT INTO s.test1 values('je suis u2 et je ne peux pas écrire dans test1');
ERROR:  permission denied for relation test1

Or c'est le comportement voulu  tel que décrit plus haut dans la discussion:

"Uniquement les droits de lecture", ça veut dire qu'une tentative d'écriture doit être rejetée, et c'est bien ce qui se passe.

Pour l'erreur de syntaxe, le corps du bloc DO doit être dans une chaîne de caractères. La syntaxe complète copier-collable dans une fenêtre SQL doit être

DO $$
DECLARE
  s text;
BEGIN
 FOR s IN SELECT schema_name FROM information_schema.schemata
 LOOP
   EXECUTE format('GRANT USAGE ON SCHEMA %I TO sig_bassee', s);
 END LOOP;
END;
$$ language plpgsql;

sachant que $$ peut être remplacé par $body$ ou $âutrechose$ si le corps du code utilise déjà ce séparateur.

Il faut boucler sur le résultat d'une requête listant les schémas concernés, et il faut déclarer explicitement une variable pour ça.

DO
DECLARE
  s text;
BEGIN
 FOR s IN SELECT schema_name FROM information_schema.schemata
 LOOP
   EXECUTE format('GRANT USAGE ON SCHEMA %I TO sig_bassee', s);
 END LOOP;
END;

Il est assez facile généralement de scripter ces ordres GRANT. Les schémas existants peuvent être listés via la table système  pg_namespace ou la vue information_schema.schemata qui est plus sélective.

Avec un psql récent (9.6) on peut écrire quelque chose du style:

 SELECT format('GRANT USAGE ON SCHEMA %I TO nom_du_role', schema_name)
    FROM information_schema.schemata \gexec

Le SELECT va générer les ordres de GRANT, et \gexec va directement exécuter ces ordres sans qu'il y ait besoin de plus de code.
On peut remplacer \gexec  par \g pour voir les requêtes sans les exécuter dans la phase de mise au point.

Le faire en plpgsql est un peu plus compliqué mais pas bien méchant non plus: dans un bloc DO, un EXECUTE pour chaque GRANT généré à l'intérieur d'un LOOP sur la requête de sélection de schémas.

Le ORDER BY n'a pas le droit d'être à cette place (dans la clause where), et la partie $$ OR $$ ,$P{Customer_ID} IS NULL , $$ doit aussi être découpée pour que $P{Customer_ID}  soit tout seul en dehors de la chaîne de caractères.

Ce qui serait intéressant c'est d'avoir toute la requête telle qu'elle arrive à postgres, elle doit être dans le log postgresql si elle n'est pas dans le message d'erreur.

Le problème est que si $P{Customer_ID} se présente comme une chaîne vide, le résultat SQL va ressembler à
...Customer_ID = OR IS NULL...
ce qui est syntaxiquement doublement faux du point de vue de l'interpréteur SQL.

Mais est-ce que c'est ça qui se produit? Par quoi exactement $P{Customer_ID}  est remplacé?
Par '' (chaîne vide mais litéral SQL valide)?
Par rien du tout?
Par le mot-clef NULL?

Il y en a pas mal. Les dédiés:

https://wiki.postgresql.org/wiki/Monito … _solutions

Beaucoup d'outils de surveillance génériques ont aussi des plugins PostgreSQL:

https://wiki.postgresql.org/wiki/Monito … th_plugins

Voir aussi une présentation de 2016 en français à ce sujet:
http://blog.taadeem.net/french/2016/04/ … PostgreSQL

Un élément essentiel pour configurer ça est l'origine de la connexion. Cet utilisateur distant doit pouvoir se connecter à partir d'où, et est-ce que l'entreprise/organisation où se trouve votre PC autorise effectivement les connexions vers votre PC depuis cet extérieur? Si cet extérieur est "tout l'Internet" généralement la réponse à la 2eme question est Non, parce que la réponse Oui est très problématique pour la sécurité.

C'est un choix à faire. Soit vous communiquez à l'autre utilisateur un login déjà existant, celui que vous utilisez vous-même, ce qui simplifie beaucoup les choses mais lui donne les mêmes droits que vous. Soit il a un login personnel mais il faudra dans ce cas gérer ses droits d'accès aux objets en base avec des commandes GRANT, ce qui peut être assez fastidieux.

Personnellement j'essaierais avec beaucoup plus de swap, au moins 2 fois la RAM, soit 64GB.

Un swap trop faible fait que le noyau ne peut pas décharger les pages qui ne lui servent pas dans l'immédiat. Du coup il est obligé de swapper plus fréquemment, ce qui aggrave le problème du point de vue de l'utilisateur.

Un autre aspect du problème est que la consommation de RAM dépend des requêtes. Certaines requêtes peuvent être gourmandes. En principe les opérations de jointure, hachage etc...sont capables d'écrire des données temporaires sur disque quand work_mem est dépassé. Mais il peut aussi se tromper dans l'estimation de la mémoire nécessaire et allouer beaucoup plus que prévu. Pour cet aspect-là il faut regarder quelles sont les requêtes en exécution quand les problèmes surviennent et étudier leur conso réelle avec EXPLAIN ANALYZE (commencer peut-être par auto_explain).