Comment corriger "ERROR : column c.relhasoids does not exist" dans Postgres ?

Question

J'essaie de CREATE TABLE dans Postgresql. Après avoir créé une table, si je tape dans TABLEAU nom du tableau ça marche.

Mais je frappe dans \d nom du tableau Je continue à obtenir l'erreur suivante.

ERROR: column c.relhasoids does not exist LINE 1: ...riggers, c.relrowsecurity, c.relforcerowsecurity, c.relhasoi...

J'ai essayé DROP DATABASE nom du tableau recréé une base de données et recréé une table à nouveau plusieurs fois. Mais cela n'a pas fonctionné.

Toute suggestion serait appréciée ! Merci.

Answer 1

Je suis capable de reproduire votre erreur si j'utilise Postgres v.12 et un client plus ancien (v.11 ou antérieur) :

[root@def /]# psql -h 172.17.0.3
psql (11.5, server 12.0)
WARNING: psql major version 11, server major version 12.
         Some psql features might not work.
Type "help" for help.

postgres=# create table mytable (id int, name text);
CREATE TABLE
postgres=# table mytable;
 id | name 
----+------
(0 rows)

postgres=# \d mytable;
ERROR:  column c.relhasoids does not exist
LINE 1: ...riggers, c.relrowsecurity, c.relforcerowsecurity, c.relhasoi...
                                                             ^
postgres=# 

C'est parce que dans le v. 12, les OID des tables ne sont plus traités comme des colonnes spéciales et donc le relhasoids n'est plus nécessaire. Veuillez vous assurer que vous utilisez une v. 12 psql pour ne pas rencontrer cette erreur.

Vous n'utilisez pas nécessairement psql La réponse la plus générale est donc de s'assurer que vous utilisez un client compatible.

Answer 2

Pour tous ceux qui courent Postgres en tant que Docker conteneur :

Au lieu d'exécuter psql depuis l'hôte, exécutez-le depuis l'intérieur du conteneur, par ex.

docker exec -it postgres_container_name psql your_connection_string

Le site Postgres est toujours livrée avec la version correspondante - et donc toujours mise à jour - de l'application psql Vous n'avez donc pas à vous soucier d'avoir la bonne version installée sur la machine hôte.

Answer 3

Si vous utilisez DataGrip, il y a une solution facile :

Essayez d'utiliser "Introspect using JDBC metadata". Cela m'a permis de résoudre le problème lorsque (je pense) j'avais un décalage de version entre le serveur postgresql et le client DataGrip.

Dans vos paramètres de connexion -> onglet Options -> cochez la case Introspect utilisant les métadonnées JDBC.

Selon https://www.jetbrains.com/help/datagrip/data-sources-and-drivers-dialog.html#optionsTab :

Passez à l'introspecteur basé sur JDBC.

Pour récupérer des informations sur les objets de la base de données (métadonnées DB), DataGrip utilise les introspecteurs suivants :

1. Un introspecteur natif (peut être indisponible pour certains SGBD). Le site introspecteur natif utilise les tables et les vues spécifiques au SGBD comme source de métadonnées. Il peut récupérer des détails spécifiques au SGBD et produire une image plus précise de la base de données. une image plus précise des objets de la base de données.

2. Un introspecteur basé sur JDBC (disponible pour tous les SGBD). L'introspecteur basé sur JDBC utilise les métadonnées fournies par le pilote JDBC. Il peut récupérer uniquement des informations standard sur les objets de la base de données et leurs propriétés.

Envisagez l'utilisation de l'intorspector basé sur JDBC lorsque la version native de échoue ou n'est pas disponible.

L'introspecteur natif peut échouer, lorsque la version de votre serveur de base de données est plus ancienne que la version minimale supportée par DataGrip.

Vous pouvez essayer de passer à l'introspecteur basé sur JDBC pour résoudre les problèmes. de récupération des informations sur la structure de votre base de données. Par exemple, lorsque les schémas qui existent dans votre base de données ou les objets de la base de données au-dessous du niveau du schéma ne sont pas affichés dans l'outil Base de données. de base de données au-dessous du niveau du schéma ne sont pas affichés dans la fenêtre de l'outil de base de données. de base de données.

Answer 4

Le problème est que le client ( psql ) est une version différente de celle du serveur postgres. J'ai vu ce problème avec la version 11 de psql parlant à la version 12 de postgres. Pour résoudre ce problème, mettez à jour la version psql à 12.

Si vous utilisez un docker postgres, vous pouvez exécuter dans le conteneur puis utiliser le client psql qui y est installé.

# get the container id with this
docker ps
# Then exec into the container, please note the host will now be 120.0.0.1
docker exec -it c12e8c6b8eb5 /bin/bash

Answer 5

J'ai eu ce problème parce que mon psql était 9.2 et la version du serveur était 12.7. Donc ... clairement le client psql doit être mis à jour. Mais comment ?

Avant de télécharger/installer quoi que ce soit, vous avez peut-être déjà la bonne version. Dans mon cas, c'est le cas.

J'ai exécuté which psql qui a montré que ma version provenait de /usr/bin/psql . J'ai ensuite vérifié /usr/pgsql-12/bin et j'ai trouvé qu'il y avait un psql là-dedans. Donc tout ce que j'avais à faire était de m'assurer que psql était récupéré à partir de là. Il y a un certain nombre d'endroits qui pourraient contrôler cela ; dans mon cas, j'ai juste ajouté cette ligne à mon fichier .pgsql_profile (dans le répertoire personnel de l'utilisateur de postgres) :

export PATH="/usr/pgsql-12/bin:$PATH"

En se déconnectant et en se reconnectant en tant que postgres et en exécutant which psql a montré que le changement avait réussi :

 which psql
/usr/pgsql-12/bin/psql