Re: Problem PL/Python-Stored Procedure und BYTEA

From: "Albe Laurenz" <all(at)adv(dot)magwien(dot)gv(dot)at>
To: "Tim Frießinger" *EXTERN* <Tim(dot)Friessinger(at)gmx(dot)net>, <pgsql-de-allgemein(at)postgresql(dot)org>
Subject: Re: Problem PL/Python-Stored Procedure und BYTEA
Date: 2006-11-08 15:07:22
Message-ID: 52EF20B2E3209443BC37736D00C3C1380B524521@EXADV1.host.magwien.gv.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-de-allgemein

> Den Zugriff auf das Dateisystem für PostgreSQL habe ich mit
> Stored Procedures in Python realisiert, Rückgabe-Typ ist BYTEA.
>
> Das Problem war hier dass die Rückgabe offenbar nicht escaped
> war, und so immer nur ca. 4 Byte durchgereicht wurden. Nach
> einiger Recherche habe ich ein Stück Python-Code gefunden,
> welches die Rückgabe präpariert hat:
>
> ####
> CREATE FUNCTION read_file2(TEXT) RETURNS BYTEA AS '
> import os
> path = args[0].replace(''/'', os.sep)
> # öffne Datei im binären Lese-Modus
> fp = open(path, "rb", 0)
> ret = fp.read()
> fp.close()
> # escape String
> return ''.join(['\\%03o' % ord(x) for x in ret])
> ' LANGUAGE plpythonu;
> #####
>
> Damit hat es theoretisch schon mal geklappt: Ich konnte über
> einen Aufruf dieser Stored Procedure mittels eines
> Java-Programmes (JDBC) die Binärdaten eines Bildes auslesen,
> mit dem Java-Programm wieder zurück in eine Datei schreiben
> und hatte damit eine Kopie des Bildes.
>
> So, nach dieser langen Ausschweifung nun mein eigentliches Problem:
> Nach dem die Sache mit einem Bild geklappt hat, hat mich wohl
> der Großenwahn gepackt und ich dachte mir, dass ich ja
> vielleicht nicht nur Bilder, sondern generell Media-Daten,
> also auch Videos etc... über meine Datenbank verwalten
> könnte. Also habe ich mal eine ca. 40 MB große Datei über
> diesen Weg kopieren wollen.
> Das Resultat war, dass meine Festplatte angefangen hat wie
> wild zu rödeln und mein komplettes System unerträglich
> langsam wurde. Ich konnte nicht mal mehr ne Shell öffnen um
> den Prozess abzuschießen. Nach mind. 5 Minuten hab ich meinen
> Computer dann neugestartet. Dann hab ich mich mal mit immer
> großer werdenden Dateien vorgetastet. So bis ca. 10 MB konnte
> ich eine Datei auf diesem Wege kopieren, danach ging die
> Rödelei dann wieder los.

Erstens: Das CREATE FUNCTION-Statement, so wie es oben steht, ist
syntaktisch falsch - offenbar wurden in der 'return'-Zeile die
einfachen Hochkommata nicht verdoppelt.

Ein guter Grund, für die Funktionsdefinition $$<programmtext>$$
zu verwenden.

Ich habe die Funktion bei mir angelegt, und sie funktioniert
grundsätzlich.

Das beobachtete Problem kommt sicher vom Speicherverbrauch: die
ganze Datei wird in den Hauptspeicher geladen und als String bearbeitet.
Das System ist sicher deshalb gestorben, weil kein Hauptspeicher
mehr frei war und wahrscheinlich wie verrückt ge'page't wurde.

Mein System ist RedHat Linux auf Intel Xeon, Kernel 2.4.21-40.ELsmp,
3GB RAM, 2GB Swap, 4 Prozessoren (angezeigt).

Ich habe eine 1GB große Datei angelegt und es ausprobiert.
Der postmaster hat einen Prozessor zugemacht, der Memoryverbrauch dieses
Prozesses stieg gemütlich auf 60% (vom physischen Hauptspeicher, also etwa
2GB), dann kam

ERROR: plpython: function "read_file2" failed
DETAIL: exceptions.MemoryError:

Spricht für sich.

Einen zweiten Versuch mit einem 100MB großen File habe ich abgebrochen, als
70% Memory belegt waren und die Maschine bereits heftig swapte.

Wahrscheinlich ist Python (mit dem ich mich nicht auskenne) memoryhungrig,
vielleicht ist es auch ein Problem von PostgreSQL.

Vielleicht läßt sich die Funktion so schreiben, daß sie Memory spart?

Liebe Grüße,
Laurenz Albe

Browse pgsql-de-allgemein by date

  From Date Subject
Next Message Peter Eisentraut 2006-11-08 15:36:36 Re: Problem PL/Python-Stored Procedure und BYTEA
Previous Message Carsten Schmid 2006-11-08 15:02:34 Re: Remote acces zu Postgress: pg_hba.conf Fehler