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


464

J'utilise postgres de homebrew dans mon OS X, mais quand je redémarre mon système, parfois postgres ne démarre pas après le redémarrage, et j'ai donc essayé manuellement pour commencer avec postgres -D /usr/local/var/postgres, mais l'erreur est survenue 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 le remettre à son état d'origine, j'ai donc décidé de désinstaller l'ensemble du système postgres, puis de le réinstaller et de créer des utilisateurs, des tables, des jeux de données, etc. C'était tellement dégoûtant, mais cela se produit fréquemment sur mon système, disons une fois en quelques mois.

Alors pourquoi perd-il pg_tblspcfréquemment le fichier? Et puis-je faire quelque chose pour éviter la perte du fichier?

Je n'ai pas mis à jour mes homebrews et postgres vers la dernière version (c'est-à-dire que j'utilise la même version). De plus, tout ce que j'ai fait sur la base de données postgres est de supprimer la table et de remplir les nouvelles données chaque jour. Je n'ai pas changé d'utilisateur, de mot de passe, etc ...

EDIT (mbannert): J'ai ressenti le besoin d'ajouter cela, car le fil est le top hit sur google pour ce problème et pour beaucoup le symptôme est différent. Les homebrewers rencontreront probablement 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 vivre cela après la mise à niveau de Yosemite, vous êtes maintenant couvert pour la lecture de ce fil.


Eep, ça ne devrait vraiment, vraiment pas! Lorsque vous dites "dernière version", veuillez indiquer le numéro de version exact. Avez-vous également mis des espaces de table sur le stockage externe? où se trouve le répertoire de données PostgreSQL?
Craig Ringer

Est également pg_tblspcun répertoire . La seule façon dont je peux voir ce répertoire et juste ce répertoire disparaissant de manière aléatoire est la corruption du système de fichiers ou un scanner de virus ou un outil de synchronisation de fichiers particulièrement mal comporté.
Craig Ringer

Je n'ai pas de scanner de virus. Je ne sais pas ce que tablespacesc'est, donc je ne pense pas que je l'ai mis sur un stockage externe.
Blaszard

Hm. Tout ce que je peux vous dire, c'est que quelque chose ne va vraiment pas. pg_tblspcne disparaît pas sur n'importe quel système que j'ai jamais rencontré, et je ne peux pas imaginer une raison sensée. Il va être très difficile de dire ce qui rend votre système différent sans beaucoup plus de détails.
Craig Ringer

2
Avez-vous pu trouver une solution pour ce @Gardecolo? J'ai le même problème après la mise à niveau vers Yosemite.
Donovan

Réponses:


928

Résolu ... en partie.

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

Pour résoudre ce problème, il vous suffit de recréer 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}/

La réexécution pg_ctl start -D /usr/local/var/postgresdémarre maintenant le serveur normalement et, au moins pour moi, sans aucune perte de données.

MISE À 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, j'ai continué et créé un fichier «.keep» dans chaque répertoire pour éviter toute suppression future.

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

Remarque : La création du .keepfichier dans ces répertoires créera du bruit dans votre fichier journal, mais ne semble pas affecter négativement autre chose.


53
Juste une suggestion pour une commande plus concise: mkdir -p /usr/local/var/postgres/{pg_tblspc,pg_twophase,pg_stat_tmp}/ettouch /usr/local/var/postgres/{pg_tblspc,pg_twophase,pg_stat_tmp}/.keep
Nate

26
Ces fichiers .keep me causent du chagrin dans les journaux du serveur:could not open temporary-files directory "pg_tblspc/.keep/PG_9.3_201306121/pgsql_tmp": Not a directory
funwhilelost

13
Il me manquait également les répertoires pg_snapshots et pg_stat.
Jon Stevens

8
J'ai également dû créer un répertoire supplémentaire 'pg_replslot'. Sauf que ça marche bien. Merci!
Lucas

6
même expérience que @Lucas pour les postgres en bouteille 9.4.0. Je devais mkdir /usr/local/var/postgres/{pg_tblspc,pg_twophase,pg_stat_tmp,pg_replslot}
Patrick Farrell

9

La réponse de Donavan est juste, je voulais juste ajouter que comme je faisais différentes choses avec la base de données (par exemple rake db:test), elle cherchait des répertoires différents qui n’ont pas été mentionnés ci-dessus et s’étoufferait quand ils n’étaient pas présents, dans mon cas pg_logical/mappings, vous pouvez donc configurer un terminal exécutant:

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

et surveillez les dossiers manquants pendant que vous parcourez vos activités de base de données typiques.


3
Nécessaire pour ajouter mkdir -p / usr / local / var / postgres / pg_logical / {snapshots, mappings}
peter_v

6

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'ai eu le même problème que ci-dessus ET j'ai eu un problème avec PostgreSQL "apparemment" fonctionnant en arrière-plan, donc même après avoir ajouté des répertoires, je ne pouvais pas redémarrer. J'ai essayé d'utiliser pg_ctl stop -m fastpour tuer le serveur PostgreSQL mais pas de chance. J'ai également 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 .plistfichier 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.


Mon plist a été nommé légèrement différemment: launchctl unload ${HOME}/Library/LaunchAgents/homebrew.mxcl.postgresql.plistmais au fond, c'était aussi le même problème pour moi, et la même solution.
onekiloparsec

4

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 .plistfichier recommandé par homebrew qui démarre PostgreSQL, vous pouvez y trouver le répertoire de données:

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

(c'est l' -Doption avec laquelle vous avez commencé postgres :)

  <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, comme ceci:

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}

-20

La création des répertoires manquants fonctionne certainement mais je l'ai corrigée en réinitialisant postgres db, c'est une approche plus propre pour éviter de futurs problèmes.

REMARQUE: cette approche supprimera les bases de données existantes

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

19
De toute évidence, la suppression de bases de données existantes n'est pas une exception mineure ici. Cela revient un peu à dire "Je n'ai pas pu trouver / var / tmp donc j'ai réinstallé le système d'exploitation".
Adam Donahue

4
Oh, mec, c'est "plus propre" que tout ce à quoi je peux penser :) J'espère juste qu'un copieur-copieur aléatoire de l'interwebz ne tirera pas cela directement dans leur console sans le regarder :)
Halil Özgür

2
Désolé pour le vote négatif Greg mais je recommande de reformuler votre solution pour qu'il soit explicite que cette approche ne doit être utilisée qu'en développement ou si l'utilisateur peut se permettre d'effacer sa base de données.
hraynaud

1
Pourquoi ce vote est-il si bas? Sur un serveur de développement, c'est la bonne façon.
Jordon Bedwell

@JordonBedwell même sur un serveur de développement est une mauvaise idée, à moins que vous ne jouiez avec une seule application en utilisant db sur votre ordinateur .. C'est comme "Je ne peux pas démarrer mon éditeur de code préféré, réinstallons le système d'exploitation"
Andre Figueiredo
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.