Du könntest in deiner Anwendung mal testweise autocommit ausschalten. Autocommit bedeutet, das jeder Befehl in PostgreSQL in eine Transaktion gekapselt wird. Sobald ein Befehl abgeschlossen ist, wird eine neue Transaktion gestartet ... die dann herumsitzt und wartet, bis der nächste Befehl ankommt.
Ausschalten tut man das in der Anwendung bei den Verbindungseinstellungen.
Übrigens ist deine "Definition" einer Transaktion auch nicht richtig.
Es ist falsch, das ein SELECT keine Daten ändert. Im Gegenteil, durch den Select können Funktionen aufgerufen werden, die intern trotzdem Daten verändern.
Aus diesem Grund wird jede Operation in einer Transaktion abgearbeitet, die du entweder in deiner Anwendung explizit startest oder die implizit von PostgreSQL gestartet wird (autocommit). Wird die Leseoperation erfolgreich beendet: schön. Gab es beim Lesen einen Fehler, können alle ev. aufgetretenen Änderungen zurückgerollt werden.
Du hast Recht, das ein SELECT nicht blockierend ist, im Normalfall jedenfalls. Dein Problem ist, das die zweite Operation, die DDL-Änderung, einen sehr exklusiven Lock auf die Tabelle benötigt. Dieser Lock sperrt auch einen SELECT aus.
Und was ich mich die ganze Zeit frage: was ist das für eine Tabellenänderung, die ihr da durchführt und warum stellt die ein Problem dar? Sprich, wie häufig führt ihr diese Änderung durch?
Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören
Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler
PostgreSQL Service & Support
--
https://www.xing.com/profile/Andreas_Kretschmer7ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
Wieso einschalten?
Wenn ich den Standard richtig lese, ist das erzwingen einer Transaktion sowieso vorgeschrieben (nebenbei: wieder ein Punkt, gegen den Mysql verstößt?). Mit aktiviertem Autocommit (Default) wird nach jedem SQL Befehl ein COMMIT durchgeführt. Mit deaktiviertem Autocommit muss man das selbst erledigen.
Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören
Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler
PostgreSQL Service & Support
Weil die Anwendung 'idle in transaction' ist. Sicheres Zeichen für "\set AUTOCOMMIT off" (steht in meiner ~/.psqlrc). Und ja: wenn es deaktiviert ist, muß man selbst das COMMIT schicken. Tut die Anwendung nicht.
Deswegen: mal einschalten, falls es geht. Dann dürfte ein select from foo anschließend ein alter foo einer anderen Anwendung nicht blockieren, weil ja ein AUTOCOMMIT kam. Okay?
Andreas
--
https://www.xing.com/profile/Andreas_Kretschmer7ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
moin,
Zu Deinem Beispiel:Dann dürfte ein select from foo anschließend ein alter foo einer anderen Anwendung nicht blockieren, weil ja ein AUTOCOMMIT kam. Okay?
nach einem Select auf die FOO ist es irrelevant auf welche Tabelle ich ein ALTER absetzte!!! ...es sind alle Blockiert!
Autocommit: Nicht möglich das es etliche Befehle in der Anwendung gibt bei denen ein Autocommit das gewünschte unterbinden würde.
... Frust...
Es handelt sich um eine Standarsoftware (= Normal-User) und einen Part für Admins. In dem Adminpart kann man ausschliesslich über die Software Tabellen ändern, Attribute hinzufügen, Löschen, ändern usw.Und was ich mich die ganze Zeit frage: was ist das für eine Tabellenänderung, die ihr da durchführt und warum stellt die ein Problem dar? Sprich, wie häufig führt ihr diese Änderung durch?
Also die gesamte Anwendung so konfigurieren wie man es möchte und ist nicht abhängig von Programmierung.
Ciao
Geändert von Vierm (15.11.2007 um 09:55 Uhr)
Links: Tobias Bauer - IT- und Funkdienstleistungen - Bilderrahmen-kaufen.de - Der Onlineshop für Bilderrahmen & Fotorahmen - Funkforum
Lesezeichen