[Python-de] Möglicher Fehler im Postgres-Treiber 'pg8000'

[Diez B. Roggisch]

On Apr 13, 2013, at 7:00 PM, Volker Böhm wrote:

> Am Sat, 13 Apr 2013 18:09:17 +0200 schrieb Diez B. Roggisch:
> 
>> Ich finde es komisch, dass du zwei Cursor aufmachst, von denen einer
>> ueber Transaktionen hinweg aufgehalten wird. Das ist IMHO unsauber und
>> undefiniert.
> 
> Finde ich gar nicht. Ich arbeite seit mehr als zehn Jahren mit Postgres 
> (meist mit Java aber auch mit Python, früher mit Perl) und habe noch nie 
> von einem Programm aus mehr als eine Connection im selben Thread 
> aufgemacht. In einem Dutzend Methoden mit drei bis acht Queries und 
> Update-Statements zu arbeiten, halte ich für einen ganz normalen Vorgang; 
> und _selbstverständlich_ auf einer einzigen Connection, weil man - 
> zumindest wenn man mit Transaktionen arbeitet - sich sonst viel zu 
> schnell einen Deadlock produziert.

Das ist nicht das, was ich gesagt habe. Das komische sind nicht die verschiedenen Cursor, sondern deren Nutzung ueber Transaktionsgrenzen hinweg. Das habe ich noch nie so gemacht (oder machen muessen). Und es ist auch semantisch finde ich hoechst fraglich: was bekommt denn ein Cursor zu sehen, der mit einem bestimmten Transaktions-Isolations-Level läuft, wenn du zwischendurch ein COMMIT machst, das Daten anderer Cursor zurueckgeschrieben hat. Sind die dann sichtbar, unsichtbar, undefiniert?

Und weil das so kompliziert ist, kann Postgres das auch nicht. So einfach ist das :)

http://www.postgresql.org/docs/9.1/static/plpgsql-cursors.html

39.7.3. Using Cursors

All portals are implicitly closed at transaction end. Therefore a refcursor value is usable to reference an open cursor only until the end of the transaction.


> Ja, wenn mir nicht noch jemand nachweist, dass ich groben Bockmist 
> verzapft habe :-) werde ich das wohl auf tun. Denn pg8000 ist wohl 
> derzeit der einzige native Python-Treiber für Postgres 2.x.. Und mit den 
> anderen Treibern, die eine DLL benutzen, kämpfe ich gerade unter cygwin :-

Denke ich habe ich nachgewiesen ;) Wenn psycopg2 et al das unterstuetzen, dann ist das also eher feature statt bug. Das kannst du natuerlich beantragen. Ich frage mich natuerlich jetzt, *WIE* psycopg2 das denn genau macht. Denn offensichtlich sind interne Strukturen der Postgres DB dazu nicht vorbereitet, und so muesste zb ein implizites tracking des lese-fortschrittes erfolgen. Kann ich mir schwer vorstellen.

Ein kurzer Blick in den Sourccode von psycopg2 ist da auch nicht erhellend, die benutzen auch einfach deklarierte Cursor.

UU liegt es an anderen Default-Transaktions-Verhaltensweisen - zB Autocommit oder sowas - zwischen den Adapter-Implementierungen.

Diez

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://mail.python.org/pipermail/python-de/attachments/20130413/7e7e629e/attachment-0001.html>