cache lookup failed for language

Hallo,

zuerst einmal: bis vor ein paar Wochen hatte ich noch keine Ahnung von Postgre. Durch Einlesen und Erfahrung mit MySql habe ich mich bisher bei Problemen immer durchschlagen können … bis jetzt:

folgendes Problem: Ich bin dabei stored procedures auf einen anderen Server zu übertragen. Diese Funktionen sind in plpgsql geschrieben. Die language habe ich erstellt und sie ist auch in pg_language vorhanden.
Allerdings tritt beim Aufruf einer Funktion der folgende Fehler auf:

cache lookup failed for language 18217

“Vakuum full” habe ich schon probiert: ändert nichts an der Situation
Postgre Version ist 8.4.4
Hilfe konnte ich bisher in weder in der Doku noch bei Google finden :rolleyes: , daher hoffe ich, dass mir hier jmd helfen kann.

Danke schonmal im Vorraus für eure Mühen,
guerilla

Wie genau sieht deine Stored Procedure aus?

Oh, und das heißt PostgreSQL, alternativ Postgres :wink:

Ich glaube zwar nicht, dass es an der Funktion selber liegt, da sie auf dem alten Server (Version 8.2.7) einwandfrei lief, aber ok; hier ist sie:

CREATE OR REPLACE FUNCTION a.user__entry(data_entries text[], pk_entry text[], fk1 text[], fk2 text[])
  RETURNS boolean AS
$BODY$

 DECLARE

 no_PK_constraint boolean := FALSE;

 n_PK integer := (select array_upper (PK_entry,1));

 PK integer := (select get_primarykey ('user_', PK_entry[1:n_PK]));

 n_FK1 integer := (select array_upper(FK1, 1));

 FK1 integer := (select get_primarykey ('location', FK1[1:n_FK1]));

 n_FK2 integer := (select array_upper(FK2, 1));

 FK2 integer := (select get_primarykey ('admindata', FK2[1:n_FK2]));

 insert_into varchar;

 BEGIN

 IF (PK=0) then

    no_PK_constraint := TRUE;

     perform primarykey_entry('user_', PK_entry[1:n_PK]);

     PK:=(select get_primarykey ('user_', PK_entry[1:n_PK]));

     insert_into := 'insert into user_(u_usertype, u_loginname, u_displayname, u_fullname, u_firstname, u_lastname, u_organization, u_adress_streetname, u_adress_city, u_adress_stateprov, u_adress_country, u_adress_postalcode, u_adress_othertext, u_email, u_picturefilename, u_imagetype, u_pager, u_fax, u_phone, u_ref_locationoid, u_certificate, u_pk, u_fk_location, u_fk_admindata) values (';

 FOR i IN 1..21 LOOP

  IF (data_entries[i]='default' or data_entries[i]='' or data_entries[i]='null' or data_entries[i] is null) then

      insert_into=insert_into||'default, ';   elseif (data_entries[i]<>'default' or data_entries[i]<>'' or data_entries[i]<>'null' or data_entries[i]<>null) then

      insert_into:=insert_into||''''||data_entries[i]||''''||', ';

  END IF;

 END LOOP;

 insert_into := insert_into||''''||PK||'''';

 IF (FK1 IS NOT NULL) THEN insert_into := insert_into||', '||''''||FK1||'''';

ELSE insert_into := insert_into||', DEFAULT';

END IF;

IF (FK2 IS NOT NULL) THEN insert_into := insert_into||', '||''''||FK2||'''';

ELSE insert_into := insert_into||', DEFAULT';

END IF;

 insert_into := insert_into||');';

 EXECUTE insert_into;

END IF;

RETURN no_PK_constraint;

END;

$BODY$
  LANGUAGE plpgsql VOLATILE SECURITY DEFINER
  COST 100;
ALTER FUNCTION a.user__entry(text[], text[], text[], text[]) OWNER TO postgres;

alle Funktionen die in dieser Funktion aufgerufen werden existieren und sind ebenfalls in plpsql geschrieben.

PS: sry, aber ich habe mich ja schon vorher als Newbie “geoutet” :wink:

Sieht auf den ersten Blick richtig aus.
Kannst du einen kleinen Testcase bereitstellen, mit dem man den Fehler nachvollziehen kann?
Also passende Tabellendefinitionen, den Code der Funktionen und wie du das aufrufst?

da wie du schon an dieser Funktion erkennen kannst, werden mehrere Funktionen in der Funktion selber aufgerufen. Mit einem kleinen Testcase ist es da leider nicht getan, da das Projekt schon ziemlich komplex ist.

Kann man vlt den Cache flushen? Kann man von der im Fehler auftauchenden “language 18217” auf eine bestimmte Sprache schließen die gefordert wird oder ist das eine OID?

edit:
sollte so ein Fall nicht eigendlich schon unmöglich sein? Ich meine, dass beim erstellen einer Funktion darauf geachtet wird ob die geforderte Sprache auch erstellt worden ist. Durch die Abhängigkeiten sollte es auch unmöglich sein eine Sprache im Nachhinein zu löschen ohne auch die Funktion die sie vorraussetzt zu löschen, oder sehe ich das falsch?

Das siehst du an sich richtig. In 8.4 sollten auch Probleme mit vorbereiteten Anfragen nicht mehr auftauchen, aber die verwendest du sowieso nicht.
Von daher weiß ich aus dem Stehgreif nicht, woran das liegen kann. Die OID ist die OID der Sprache.

SELECT oid, * FROM pg_language;

Kann man ggf. von Remote auf die Datenbank schauen, wenn das so umfangreich ist?

Kann das Lookup nicht auch ganz simpel aufgrund defekter Hardware fehlschlagen (wäre nicht das erste mal…)?
D. h. ja m . E. nichts weiter, also dass die angeforderten Daten weder auf der Platte noch im RAM zu finden sind.
Seid ihr sicher, dass die Maschine, auf der die DB läuft, in Ordnung ist?

Da müsste es dann imho Fehlermeldungen ala “relation xyz not found” regnen …