Question `pg_tblspc` manquant après l'installation de la dernière version d'OS X (Yosemite ou El Capitan)


J'utilise postgres de homebrew dans mon OS X, mais quand je redémarre mon système, parfois le postgres ne démarre pas après le redémarrage, et j'ai donc essayé manuellement de le démarrer avec postgres -D /usr/local/var/postgres, mais l'erreur s'est produite avec le message suivant: FATAL: could not open directory "pg_tblspc": No such file or directory.

La dernière fois que cela s’est produit, je n’ai pas pu l’amener à l’état initial, alors j'ai décidé de désinstaller tout le système postgres, puis de le réinstaller et de créer des utilisateurs, des tables, des jeux de données, etc. Cela arrive souvent sur mon système, disons une fois dans quelques mois.

Alors pourquoi perd-il le pg_tblspc fichier fréquemment? Et y a-t-il quelque chose que je puisse faire pour éviter la perte du fichier?

Je n'ai pas mis à niveau mon homebrew et mes postgres vers la dernière version (c'est-à-dire que j'utilise la même version). En outre, toutes les choses que j'ai faites sur la base de données postgres sont supprimer la table et remplir les nouvelles données tous les jours. Je n'ai pas changé d'utilisateur, mot de passe, etc ...

EDIT (mbannert): J'ai senti le besoin d'ajouter ceci, puisque le thread est le plus grand succès sur Google pour ce problème et pour beaucoup le symptôme est différent. Homebrewers va probablement rencontrer ce message d'erreur:

No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/tmp/.s.PGSQL.5432"?

Donc, si vous venez de l'expérimenter après la mise à niveau de Yosemite, vous êtes maintenant couvert pour le moment.


452
2017-09-22 08:57


origine


Réponses:


Résolu ... en partie.

Apparemment, l’installation des dernières versions d’OS X (par exemple, Yosemite ou El Capitan) supprime certains répertoires /usr/local/var/postgres.

Pour résoudre ce problème, recréez simplement les répertoires manquants:

mkdir /usr/local/var/postgres/pg_tblspc
mkdir /usr/local/var/postgres/pg_twophase
mkdir /usr/local/var/postgres/pg_stat
mkdir /usr/local/var/postgres/pg_stat_tmp
mkdir /usr/local/var/postgres/pg_replslot
mkdir /usr/local/var/postgres/pg_snapshots

Ou, plus concis (grâce à Nate):

mkdir /usr/local/var/postgres/{pg_tblspc,pg_twophase,pg_stat,pg_stat_tmp,pg_replslot,pg_snapshots}/

Rerunning pg_ctl start -D /usr/local/var/postgres maintenant démarre le serveur normalement et, au moins pour moi, sans aucune perte de données.

METTRE À JOUR

Sur mon système, certains de ces répertoires sont vides même lorsque Postgres est en cours d'exécution. Peut-être que dans le cadre d'une opération de "nettoyage", Yosemite supprime tous les répertoires vides? Dans tous les cas, je suis allé de l'avant et créé un fichier '.keep' dans chaque répertoire pour empêcher toute future suppression.

touch /usr/local/var/postgres/{pg_tblspc,pg_twophase,pg_stat,pg_stat_tmp,pg_replslot,pg_snapshots}/.keep

Remarque: Création du .keep fichier dans ces répertoires va créer du bruit dans votre fichier journal, mais ne semble pas affecter négativement quoi que ce soit d'autre.


919
2017-09-23 17:55



DonavanLa réponse est sur le coup, je voulais juste ajouter que comme j'ai fait des choses différentes avec la base de données (par ex. rake db:test), il a cherché différents répertoires qui n’ont pas été mentionnés ci-dessus et qui seraient étranglés en leur absence, dans mon cas pg_logical/mappings, vous souhaiterez peut-être configurer un terminal en cours d'exécution:

tail -f /usr/local/var/postgres/server.log

et regardez-le pour les dossiers manquants pendant que vous allez à travers vos activités de base de données typiques.


9
2018-02-21 14:51



Ceci est légèrement hors-sujet mais mérite d'être noté ici dans le cadre du processus de récupération de PostgreSQL Yosemite. J'avais le même problème que ci-dessus ET j'avais un problème avec "apparemment" PostgreSQL s'exécutait en arrière-plan, donc même après l'ajout de répertoires, je ne pouvais pas redémarrer. J'ai essayé d'utiliser pg_ctl stop -m fast pour tuer le serveur PostgreSQL mais pas de chance. J'ai aussi essayé d'aller directement après le processus avec kill PIDmais dès que je l'ai fait, un processus PostgreSQL est réapparu avec un PID différent.

La clé a fini par être un .plist dossier que Homebrew avait chargé ... Le correctif pour moi a fini par être:

launchctl unload /Users/me/Library/LaunchAgents/homebrew.mxcl.postgresql92.plist

Après cela, j'ai pu démarrer PostgreSQL normalement.


6
2017-10-30 17:00



Les répertoires manquants doivent être présents dans votre répertoire de données PostgreSQL. Le répertoire de données par défaut est /usr/local/var/postgres/. Si vous avez configuré un répertoire de données différent, vous devez y recréer les répertoires manquants. Si vous avez modifié le homebrew recommandé .plist fichier qui démarre PostgreSQL, vous pouvez y trouver le répertoire de données:

cat ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist

(C'est le -D option que vous avez commencé postgres avec :)

  <key>ProgramArguments</key>
  <array>
    <string>/usr/local/bin/postgres</string>
    <string>-D</string>
    <string>/usr/local/pgsql/data</string>

Dans l'exemple ci-dessus, vous créez les répertoires manquants dans /usr/local/pgsql/data, ainsi:

cd /usr/local/pgsql/data
mkdir {pg_tblspc,pg_twophase,pg_stat,pg_stat_tmp,pg_replslot,pg_snapshots,pg_logical}
mkdir pg_logical/{snapshots,mappings}

4
2018-05-18 16:48



La création des répertoires manquants fonctionne certes mais je l'ai corrigé en réinitialisant la base de données postgres, c'est une approche plus propre pour éviter les problèmes futurs.

NOTE: Cette approche va supprimer les bases de données existantes

$ rm -r /usr/local/var/postgres
$ initdb -D /usr/local/var/postgres

-22
2017-10-18 03:47