Et est-ce que vous cherchez toujours le même motif, ou bien des motifs qui changent ? (sait-on jamais)

ah. oui, comme écrit dans la doc, "Asynchronous operation is more efficient because it can reuse connections and take advantage of parallelism". mettez déjà "archive-async=y" . il vous faudra certainement aussi définir un spool-path

Oui, il doit y avoir moyen, mais j'ai vraiment l'impression qu'il est rendondant avec les autres. Sinon vous pouvez le découper, à coup de st_intersection par exemple (avec votre grille ?), ou de st_subdivide ?

Il vaudrait mieux un dump de la base, histoire de pouvoir reproduire le problème... parce que là, on peut en faire un peu ce qu'on veut, des gpkg

C'est normal. Il y a des "frais fixes" pour un enregistrement dans les bases de données. On a un entête de bloc de taille fixe, et un entête d'enregistrement, de taille fixe aussi. C'est bien détaillé ici: https://www.postgresql.org/docs/current … ayout.html

L'entête de bloc est souvent négligeable. L'entête d'enregistrement beaucoup moins… c'est 23 octets sous Postgres.

Ok. Un dernier piège… un utilisateur pourrait tenter, par la vue, de changer id_reseau ¸ res_noeud.type_noeud ou res_noeud.date_suppression IS NULL. Et donc faire "disparaître" des données de la vue. Il vaudrait probablement mieux se prémunir de ça dans la fonction PL (un contrôle sur les insert/update dès le départ je pense)

Je pense que ce que vous voulez c'est session_user, pas current_user: https://www.postgresql.org/docs/current … -info.html

C'est exactement ce que dit la doc. Quand on fait une fonction security definer, il faut mettre un search_path restrictif (idéalement, uniquement pg_catalog, si on veut vraiment être sûr), et préfixer tous les objets auxquels on accède par leur schéma pour être vraiment explicite. Vu que c'est déjà presque bon dans votre fonction (currval('res_noeud_id_noeud_seq'::regclass) par exemple ne précise pas le schéma, il faudra le corriger), il suffit de modifier l'entête de la fonction par :

CREATE OR REPLACE FUNCTION res_eau_vanne_vue_edit()
RETURNS trigger SECURITY DEFINER SET search_path= '' AS

ou quelque chose de très approchant.

Vous pouvez le mettre avant ou après le bloc AS, ça n'a aucune importance.

Une fois que vous aurez fait ça, la fonction s'exécutera en tant que son propriétaire, et non plus en tant que l'utilisateur appelant. Faites donc bien attention à ce qu'elle appartienne à un utilisateur (role) ayant accès aux objets en question en écriture.

Si l'utilisateur n'est pas bon, vous pouvez faire un ALTER FUNCTION ... OWNER TO.

Et il faudra peut-être faire un GRANT EXECUTE sur cette fonction aux utilisateurs ayant accès à la vue (par défaut ça devrait être bon).

Je pense que le paragraphe que vous tirez de la doc, c'est pour les vues qui ne nécessitent pas de trigger instead of. Le trigger, lui, il exécute la fonction en tant que la personne connectée. À mon avis, si vous définissez la fonction comme security definer, avec comme propriétaire grp_aep_admin, ça marchera, puisque la fonction s'exécutera en tant que grp_aep_admin

Le répertoire cible d'un tablespace ne devrait pas être dans le PGDATA. Sinon vous courrez le risque de le backuper deux fois, d'avoir le système de backup qui écrase les mauvais fichiers, etc… c'est pour ça que pgbackrest refuse de backuper. Mieux vaut vous alerter maintenant.

À moins que axidata soit un point de montage vers un autre filesystem, ce tablespace n'a aucun intérêt pour postgres de toutes façons, le but d'un tablespace sous postgres, c'est juste de pouvoir utiliser un système de fichiers différent (sur un type de stockage différent par exemple) pour certains objets. Donc deux possibilités pour résoudre votre problème:
- soit axidata est un point de montage. Dans ce cas là, arrêtez l'instance, remontez le ailleurs, qui ne soit pas un sous répertoire de /axihome/base2/postgresdata/, et mettez à jour le lien symbolique (techniquement le tablespace n'est qu'un lien symbolique) de 'pg_tblspc/16432 pour pointer vers la nouvelle destination
- soit c'est juste un répertoire. dans ce cas, il ne sert vraiment à rien, vous allez plus vous compliquer la vie qu'autre chose. ramenez les objets dans le tablespace par défaut, supprimez le tablespace. ça a un sens sous oracle par exemple, parce qu'il gère des datafiles, sous postgres ça ne sert à rien.

+1. Avec pgpool, ça ne marchera pas. On a déjà essayé

Aucune idée de la cause de votre problème. Par contre, je peux vous donner un conseil: virez pgpool. C'est mauvais pour la haute dispo, la répartition de charge et la réplication. Entre les bugs et la perte de performance, il n'y a vraiment aucun cas d'utilisation valable. Quel que soit votre cas d'utilisation, il y a mieux que pgpool (à peu près tout ce que vous pourrez trouver).