\copy n'est pas une commande SQL utilisable dans une requête ou du code serveur.
C' est une méta-commande dans psql qui va déclencher un COPY nomtable FROM STDIN, puis va lire le fichier en local et envoyer son contenu au serveur à travers la connexion.

Pour lire un fichier du serveur il faut être superuser en effet. Si un superuser veut donner à un non-superuser le droit de le faire, la solution classique est de faire cette opération via  une fonction créée pour l'occasion et avec une clause SECURITY DEFINER. Tout ce que lance la fonction sera exécuté avec des droits superuser.

Sur les versions les plus récentes de PostgreSQL (11) il y a aussi un droit spécifique pg_read_server_files qui permet de lire n'importe quel fichier.
voir https://www.postgresql.org/docs/11/default-roles.html

Si cet objet n'est pas sérialisable tel quel, il faut entrer dans le détail de l'objet et comprendre quelle composante de l'objet sert à quoi, et écrire soi-même les routines objet->version sérialisée et version sérialisée->objet

Est-ce qu'il y a un index unique sur pg_database.datname ou pas?

Il faudrait voir le résultat de cette requête:

 SELECT datname, datname::bytea, md5(datname) FROM pg_database;

Un vrai doublon n'est pas impossible si l'index unique sur pg_database.datname est corrompu, mais ce n'est pas le plus probable.

Indépendamment de ça, la suppression manuelle  du répertoire fait que comme dit Guillaume, le PGDATA peut être considéré comme perdu maintenant.

current_timestamp() est l'horodatage du début de la transaction, donc il ne change pas pendant une transaction.

C'est clock_timestamp() que vous voulez ici.

Voir https://docs.postgresql.fr/11/functions-datetime.html

Vous pouvez vous connecter à la version 11 en faisant:

psql --cluster 11/main [autres options]

Vous pouvez aussi simplifier la situation en supprimant l'instance 10 si vous n'en avez plus besoin, avec pg_dropcluster, ce qui fera que le port par défaut 5432 deviendra disponible pour l'instance 11.

to_tsquery  ne permet pas de faire ça,  mais l'extension pg_trgm le permet.

On fait un index GIN ou GIST sur la colonne et il est utilisé automatiquement  par une clause LIKE colonne '%foo%' ou ILIKE colonne '%foo%'. Accessoirement pg_trgm permet aussi de reconnaître des termes saisis de manière approximative.

https://www.postgresql.org/docs/current/pgtrgm.html

Le multi-cluster est géré côté client par la couche pg_wrapper documentée ici:
http://manpages.ubuntu.com/manpages/bio … per.1.html

Côté serveur, ce sont les commandes pg_lsclusters, pg_ctlcluster etc...

http://manpages.ubuntu.com/manpages/bio … ers.1.html

En interne ces commandes vont chercher la config par cluster sous /etc/postgresql/... et ensuite se réfèrent au(x) PGDATA(s) trouvé(s) dans ces configs.

Pour que plusieurs utilisateurs puissent faire des DROP sur des objets, il faudrait que les objets appartiennent à un rôle dont ces utilisateurs sont membres. Par exemple:

CREATE ROLE createur;

GRANT createur TO user1, user2, user3;

si user1 veut créer une table, il fait

SET ROLE createur;
CREATE TABLE nomdetable(....)  -- la table appartiendra au rôle "createur"
RESET role;

Si ensuite user2 veut détruire cette table, il a le droit de faire
DROP TABLE nomdetable;

Côté logiciel vous n'utilisez à première vue que du très standard que tout le monde utilise, donc un défaut hardware est une piste possible. En particulier, une barrette mémoire défaillante peut produire ce genre de plantage récurrent.

Vous pouvez déjà vérifier si votre serveur a de la mémoire à correction d'erreur  (ECC) avec la commande
dmidecode --type memory (chercher "Error Correction Type" dans le résultat)
et si oui regarder s'il y a des erreurs dans le syslog relatives à la mémoire

On peut voir l'EXPLAIN ANALYZE de la requête lente et la requête de création de l'index composé ?

De mémoire le parser est relié à une configuration de recherche (TEXT SEARCH CONFIGURATION): on peut en avoir plusieurs par base et donner cette configuration comme argument "regconfig" aux fonctions comme to_tsvector ou to_tsquery.