Archiv des Autors: Heiko Thurat

Shell: Touch rekursiv

„touch“ ist ein Shell-Programm, dass den Zeitstempel von Dateien ändern kann. Im Normalfall wird der aktuelle Zeitstempel gesetzt. Leider gibt es keine Parameter für rekursive Bearbeitung (über mehrere Verzeichnisebenen).

Abhilfe:

find . -exec touch {} \;

Hier erledigt „find“ das filtern aller Dateien aus den Unterverzeichnissen und über den exec-Parameter wird dann „touch“ aufgerufen.

Postgresql: Prüfen, ob Replikation läuft

Als postgres-User in der psql-Console folgende Befehle eingeben:

SELECT pg_is_in_recovery();
-> muss „true“ sein

SELECT pg_last_xlog_receive_location();
-> zeigt letztes erhaltenes xlog file an

SELECT pg_last_xlog_replay_location();
-> zeigt letztes eingespielte xlog file an

SELECT pg_last_xact_replay_timestamp();
-> zeigt Timestamp der letzten Einspielung an, sollte etwa die aktuelle Uhrzeit sein

Git: Stashes löschen und alle löschen

Änderungen, die später aufgegriffen werden sollen, aber noch nicht in einen Commit wandern, die kann man mit „git stash“ erst einmal zwischenspeichern. Oft wird danach ein „git pull“ ausgeführt und vielleicht die Änderung mit „git stash apply“ wieder zurückgeholt.

Will man den stash löschen, geht das via „git stash drop“. Will man alle Stash-Einträge löschen: „git stash clear“.

Postgres: Label in ENUM-Types umbennen in Postgres 9

Postgres 10 verfügt über einen Befehl für das Umbennen von ENUM-Values. Postgres 9 nicht.

Gesetzt den Fall wir hätten ein ein ENUM-Type der Art:

CREATE TYPE purchase_type_enum AS ENUM ('undefined', 'mailorder', 'ecommerce');

Dann wollen wir den Wert „undefined“ (der so in Javascript vorkommen könnte) in „unconfigured“ umbennen. So lässt sich das in Postgres 9 lösen:

UPDATE pg_enum SET enumlabel = 'unconfigured'
WHERE enumlabel = 'undefined' AND enumtypid = (
SELECT oid FROM pg_type WHERE typname = 'purchase_type_enum'
);

Git: Kaputtes Repo neu aufbauen/reparieren

Defektes Filesystem und git pull funktioniert nicht richtig? Dann kann das Repo kaputt sein (Bezug zu parent-Einträgen nicht mehr möglich oder …) Ein meinem Fall kam nach einem git pull der ominöse Hinweis, dass das Repo aus Performance-Gründen optimiert werden sollte. Ein git gc brachte dann Fehlermeldungen. Das Repo war beschädigt.

mv -v .git .git_old &&            # (1)
git init &&                       # (2)
git remote add origin "git@gitlab.infosys.de:etacs/etacs_production.git" && # (3)
git fetch &&                      # (4)
git reset origin/master --mixed   # (5)
git pull                          # (6)
git branch --set-upstream-to=origin/master master # (7)
  1. Altes Repo sichern
  2. Neues Repo initialisieren
  3. Repo mit Remote-Repo verbinden (die URL steht in .git/config – oder nach Sichern .git_old/config))
  4. Repo aktualisieren
  5. Master Branch resetten
  6. Inhalte runterladen (wenn Git sich jetzt beschwert, dann den Upstream setzen -> 7)
  7. Upstream setzen