pg_dump: schema with OID xxxxxxxx does not exist

Hallo zusammen,

beim Versuch, eine (oder alle) DB (s) zu dumpen, erhalte ich folgenden Fehler:

postgres@kbb-meditec-bak:/meditec/medikh> pg_dump --format=plain -v --username=medikh --file=/meditec/install/pg_dump.sql mediprodpg_dump: lese Schemas
pg_dump: lese benutzerdefinierte Funktionen
pg_dump: lese benutzerdefinierte Typen
pg_dump: Schema mit OID 2200 existiert nicht
pg_dump: *** abgebrochen wegen Fehler
postgres@kbb-meditec-bak:/meditec/medikh

Wie kann ich herausfinden, was sich hinter oder OID verbirgt - und diese Inkonsistenz korrigieren?

Ich habe das ganze noch einmal mit einem höheren Debug-Level gemacht, dabei kam folgendes raus:

postgres@kbb-meditec-bak:~/data/pg_log> pg_dump --format=plain -v --username=medikh --file=/meditec/install/pg_dump.sql mediprodDEBUG:  InitPostgres
DEBUG:  StartTransaction
DEBUG:  name: unnamed; blockState:       DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children: 
DEBUG:  CommitTransaction
DEBUG:  name: unnamed; blockState:       STARTED; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children: 
pg_dump: DEBUG:  StartTransactionCommand
pg_dump: DEBUG:  StartTransaction
pg_dump: DEBUG:  name: unnamed; blockState:       DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children: 
pg_dump: DEBUG:  ProcessUtility
pg_dump: DEBUG:  CommitTransactionCommand
pg_dump: DEBUG:  CommitTransaction
pg_dump: DEBUG:  name: unnamed; blockState:       STARTED; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children: 
pg_dump: DEBUG:  StartTransactionCommand
pg_dump: DEBUG:  StartTransaction
pg_dump: DEBUG:  name: unnamed; blockState:       DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children: 
pg_dump: DEBUG:  ProcessUtility
pg_dump: DEBUG:  CommitTransactionCommand
pg_dump: DEBUG:  CommitTransaction
pg_dump: DEBUG:  name: unnamed; blockState:       STARTED; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children: 
pg_dump: DEBUG:  StartTransactionCommand
pg_dump: DEBUG:  StartTransaction
pg_dump: DEBUG:  name: unnamed; blockState:       DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children: 
pg_dump: DEBUG:  ProcessUtility
pg_dump: DEBUG:  CommitTransactionCommand
pg_dump: DEBUG:  CommitTransaction
pg_dump: DEBUG:  name: unnamed; blockState:       STARTED; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children: 
pg_dump: DEBUG:  StartTransactionCommand
pg_dump: DEBUG:  StartTransaction
pg_dump: DEBUG:  name: unnamed; blockState:       DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children: 
pg_dump: DEBUG:  ProcessUtility
pg_dump: DEBUG:  CommitTransactionCommand
pg_dump: DEBUG:  StartTransactionCommand
pg_dump: DEBUG:  ProcessUtility
pg_dump: DEBUG:  CommitTransactionCommand
pg_dump: lese Schemas
pg_dump: DEBUG:  StartTransactionCommand
pg_dump: DEBUG:  ProcessUtility
pg_dump: DEBUG:  CommitTransactionCommand
pg_dump: DEBUG:  StartTransactionCommand
pg_dump: DEBUG:  CommitTransactionCommand
pg_dump: lese benutzerdefinierte Funktionen
pg_dump: DEBUG:  StartTransactionCommand
pg_dump: DEBUG:  CommitTransactionCommand
pg_dump: lese benutzerdefinierte Typen
pg_dump: DEBUG:  StartTransactionCommand
pg_dump: DEBUG:  CommitTransactionCommand
pg_dump: Schema mit OID 2200 existiert nicht
pg_dump: *** abgebrochen wegen Fehler

Vielen Dank im Voraus!

Vermutlich geht es ja um die Tabelle pg_type.
Ein

select * from pg_type where typnamespace = 2200;

findet nichts - ist das das Problem?

In welcher Tabelle müsste ich denn dann die Referenz darauf löschen?

Moin,

hat echt keiner ne gute Idee dazu?
Es würde mir auch nicht um eine große Ursachenforschung gehen - eine Lösung wäre genug :slight_smile:

Danke, vG,

Andreas

Versuch mal:

SELECT oid, * FROM pg_class WHERE oid = 2200;

Die Query liefert leider keine Zeilen zurück.

Meine Vermutung ist aber auch, dass die Tabelle pg_type das Problem ist.
Schau mal auf folgende Zeile aus dem Protokoll:

pg_dump: lese benutzerdefinierte Typen 
pg_dump: DEBUG:  StartTransactionCommand 
pg_dump: DEBUG:  CommitTransactionCommand 
pg_dump: Schema mit OID 2200 existiert nicht 
pg_dump: *** abgebrochen wegen Fehler

Ich schätze, deine Datenbank ist kaputt.
Hast du ein Backup? Ist wohl der einfachste Weg …

Hi Andreas,

es handelt sich hier bereits um den Backup-Server. Auf dem vorherigen Produktivsystem ist das RAID und der RAM explodiert, sodass der Slave aktiviert wurde (Basebackup-WAL-Shipping). Und genau den möchte ich hier nun dumpen, um ein neues Produktivserver aufsetzen zu können.

Um also deine Frage kurz und knapp zu beantworten… Ich habe kein Backup.

Ich habe von T. Lane gelesen, dass dieses Problem auch nicht so selten vorkommt, dass es aber noch keinem gelungen ist, es zu reproduzieren und der Bug also nach wie vor im Code steckt.

Weiß jemand von euch, woher das pg_dump die Informationen holt, welche Daten zu dumpen sind? Denn innerhalb dieser Informationen muss ja auf diese OID 2200 verwiesen werden, die es nicht mehr gibt. Sprich es muss eigentlich noch eine Systemtabelle geben, in der in einem Datensatz auf den Tupel mit der OID 2200 referenziert wird.

Schemas in pg_namespace. Da kannst mit der OID nach suchen.

Andreas

Ein

SELECT oid, * FROM pg_namespace;

liefert folgendes zurück:

11;"pg_catalog";10;"{postgres=UC/postgres,=U/postgres}"
99;"pg_toast";10;""
11052;"pg_temp_1";10;""
11053;"pg_toast_temp_1";10;""
11313;"information_schema";10;"{postgres=UC/postgres,=U/postgres}"
113609250;"public";10;"{postgres=UC/postgres,=UC/postgres}"

Also auch hier ist von dieser onimösen OID 2200 nix zu sehen.

schau mal, ob relnamespace in pg_class den Wert enthält.

Andreas

Also selbst wenn du herausfindest wo dieser Eintrag fehlt - wirst du den wohl nicht wiederherstellen können. Und wer weiss, ob das der einzige fehlende/fehlerhafte Eintrag ist.

Wie viele Tabellen und Schemas kannst du in psql über \dt und \dn denn anzeigen? Und funktioniert das überhaupt?
In pg_class siehst du alle Datenbankobjekte.

Ich glaube, jetzt ist ein guter Zeitpunkt sich darüber Gedanken zu machen wie du die Daten und Objektbeschreibungen manuell aus der Datenbank extrahierst. Jedes Objekt einzeln.

Hi,

ein

SELECT 
  *
FROM 
  pg_catalog.pg_class
WHERE 
  pg_class.relnamespace = 2200;

liefert zwei Sätze zurück.

"m_clients";2200;113609247;16384;0;113609245;0;0;0;0;0;t;f;"r";27;0;0;0;0;0;t;t;f;f;56269074;"";""
"m_clients_pkey";2200;0;16384;403;128110713;0;1;0;0;0;f;f;"i";1;0;0;0;0;0;f;f;f;f;0;"";""

Zwei Sätze finde ich wie gesagt auch, wenn ich mit der OID in pg_type suche.

Also selbst wenn du herausfindest wo dieser Eintrag fehlt - wirst du den wohl nicht wiederherstellen können. Und wer weiss, ob das der einzige fehlende/fehlerhafte Eintrag ist.

Wie viele Tabellen und Schemas kannst du in psql über \dt und \dn denn anzeigen? Und funktioniert das überhaupt?
In pg_class siehst du alle Datenbankobjekte.

Ich glaube, jetzt ist ein guter Zeitpunkt sich darüber Gedanken zu machen wie du die Daten und Objektbeschreibungen manuell aus der Datenbank extrahierst. Jedes Objekt einzeln.

Da ich jedoch wie ads nicht glaube, dass ich das vernünftig wiederherstellen kann, werde ich ich Daten per Script auslesen und in einer neuen DB wieder importieren.
Bei dieser Lösung habe ich zumindest die Sicherheit, dass die Systemtabellen auch wirklich konsistent sind.

Ich danke mal wieder den “üblichen Verdächtigen”, für eure phantastische Hilfe - VIELEN DANK!

PS: @ads: \dt und \dn hat noch funktioniert. Die DB an sich läuft prima, nur pg_dump will nicht mehr.