"breche Verbindung ab wegen Absturz eines anderen Serverprozesses"

Neu installieren beseitigt - vielleicht - das Problem. Aber auch nur vielleicht.

Er hat doch aber schon geschrieben, dass die gleichen Queries auf einem anderen System problemlos durchlaufen. Ich denke schon, dass es gehen könte. Garantien gibt’s natürlich keine…

So, jetzt weiß ich auch nicht mehr weiter. Auf einem anderen Server Win2003 SBS, ebenfalls mit pg8.4, ergibt sich nun dasselbe Problem. allerdings bei einer anderen Select-Abfrage (andere Tabellen) die aber wiederum ebenfalls geschachtelt ist.
Folgendes Konstrukt schein in PG wirklich der “Killer” zu sein:

SELECT … FROM tabelle1 WHERE id IN (SELECT … FROM tabelle2 WHERE …)

Wenn ich dagegen das “IN” in ein “=” umwandle, würde es funktionieren, doch das Ergebnis wäre ein Anderes.
Bin gerade dabei mir db2-Express anzusehen! Irgendwie scheint mir das sicherer zu sein, oder kennt vielleicht irgendjemand noch einen Trick?
Ich möchte eigentlich nicht die Version 8.4 durch die 9.0 ersetzen, oder sollte ich dies probieren? Ist die 9.0 unbedenklich?

Ein Absturz der Datenbank hat in der Regel andere Gründe, die irgendwo im Bereich Hardware oder Software zu suchen sind.
Du kannst also in ähnliche oder andere Probleme mit einer anderen Datenbank laufen.

Kannst du mal den Anfrageplan (EXPLAIN) für die Anfrage hier posten?

9.0 ist gerade Beta 2 oder so, also nicht für Produktivbetrieb geeignet! 8.4 ist das aktuellste Major-Release.

Ein EXPLAIN brachte mir folgendes:

“Sort (cost=226.28…226.28 rows=1 width=165)”
" Sort Key: bsa.listenposition"
" -> Nested Loop (cost=36.07…226.27 rows=1 width=165)"
" -> Unique (cost=36.07…36.08 rows=2 width=4)"
" -> Sort (cost=36.07…36.08 rows=2 width=4)"
" Sort Key: public.rechnungen.artikelid"
" -> Seq Scan on rechnungen (cost=0.00…36.06 rows=2 width=4)"
" Filter: (rechnungsnummer = 25519)"
" -> Index Scan using bestellung_serviceartikel_pkey on bestellung_serviceartikel bsa (cost=0.00…8.27 rows=1 width=165)"
" Index Cond: (bsa.id = public.rechnungen.artikelid)"
" Filter: (bsa.auftragsid = 15841::bigint)"
" SubPlan 1"
" -> Aggregate (cost=40.09…40.35 rows=1 width=4)"
" -> Seq Scan on rechnungen (cost=0.00…40.08 rows=1 width=4)"
" Filter: ((artikeltyp = 1) AND (artikelid = $0))"
" SubPlan 2"
" -> Aggregate (cost=40.09…40.35 rows=1 width=4)"
" -> Seq Scan on rechnungen (cost=0.00…40.08 rows=1 width=4)"
" Filter: ((artikeltyp = 1) AND (artikelid = $0))"
" SubPlan 3"
" -> Aggregate (cost=40.08…40.09 rows=1 width=14)"
" -> Seq Scan on rechnungen (cost=0.00…40.08 rows=1 width=14)"
" Filter: ((artikeltyp = 1) AND (artikelid = $0))"
" SubPlan 4"
" -> Aggregate (cost=2.01…2.28 rows=1 width=4)"
" -> Seq Scan on gutschriften (cost=0.00…2.00 rows=1 width=4)"
" Filter: ((artikeltyp = 1) AND (artikelid = $0))"
" SubPlan 5"
" -> Aggregate (cost=2.01…2.28 rows=1 width=4)"
" -> Seq Scan on gutschriften (cost=0.00…2.00 rows=1 width=4)"
" Filter: ((artikeltyp = 1) AND (artikelid = $0))"
" SubPlan 6"
" -> Aggregate (cost=2.01…2.02 rows=1 width=15)"
" -> Seq Scan on gutschriften (cost=0.00…2.00 rows=1 width=15)"
" Filter: ((artikeltyp = 1) AND (artikelid = $0))"
" SubPlan 7"
" -> Seq Scan on rechnungen re (cost=0.00…44.09 rows=1 width=4)"
" Filter: ((rechnungsnummer = 25519) AND (artikelid = $0) AND (artikeltyp = 1))"
" SubPlan 8"
" -> Seq Scan on gutschriften re (cost=0.00…2.17 rows=1 width=4)"
" Filter: ((gutschriftsnummer = 25519) AND (artikelid = $0) AND (artikeltyp = 1))"

Der SQL-String sieht wie folgt aus:
SELECT * ,
(SELECT if(count(rechnungsnummer)>0,MIN(rechnungsnummer),0) FROM rechnungen WHERE artikeltyp=1 AND artikelid=bsa.id) AS min_rechnungsnummer,
(SELECT if(count(rechnungsnummer)>0,MAX(rechnungsnummer),0) FROM rechnungen WHERE artikeltyp=1 AND artikelid=bsa.id) AS max_rechnungsnummer,
(SELECT MIN(rechnungsdatum) FROM rechnungen WHERE artikeltyp=1 AND artikelid=bsa.id) AS Rechnungsdatum,
(SELECT if(count(gutschriftsnummer)>0,MIN(gutschriftsnummer),0) FROM gutschriften WHERE artikeltyp=1 AND artikelid=bsa.id) AS min_gutschriftsnummer,
(SELECT if(count(gutschriftsnummer)>0,MAX(gutschriftsnummer),0) FROM gutschriften WHERE artikeltyp=1 AND artikelid=bsa.id) AS max_gutschriftsnummer,
(SELECT MIN(gutschriftsdatum) FROM gutschriften WHERE artikeltyp=1 AND artikelid=bsa.id) AS gutschriftsdatum,
(SELECT Anzahl FROM Rechnungen AS re WHERE re.Rechnungsnummer = 25519 AND ArtikelID=bsa.id and artikeltyp=1) AS Rechnungsanzahl,
(SELECT Anzahl FROM Gutschriften AS re WHERE re.Gutschriftsnummer = 25519 AND ArtikelID=bsa.id and artikeltyp=1) AS Gutschriftsanzahl

FROM bestellung_serviceartikel as bsa
WHERE auftragsID=‘15841’
AND bsa.id IN (SELECT ArtikelID FROM Rechnungen WHERE Rechnungsnummer=25519)

ORDER BY Listenposition ASC


Die SQL-Query-konsole zeigt folgende Meldung:
_DEBUG: StartTransactionCommand
DEBUG: StartTransaction
DEBUG: name: unnamed; blockState: DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children:********** Fehler **********

_
Bei folgendem Query gibt es keine Probleme:_SELECT * ,
(SELECT if(count(rechnungsnummer)>0,MIN(rechnungsnummer),0) FROM rechnungen WHERE artikeltyp=1 AND artikelid=bsa.id) AS min_rechnungsnummer,
(SELECT if(count(rechnungsnummer)>0,MAX(rechnungsnummer),0) FROM rechnungen WHERE artikeltyp=1 AND artikelid=bsa.id) AS max_rechnungsnummer,
(SELECT MIN(rechnungsdatum) FROM rechnungen WHERE artikeltyp=1 AND artikelid=bsa.id) AS Rechnungsdatum,
(SELECT if(count(gutschriftsnummer)>0,MIN(gutschriftsnummer),0) FROM gutschriften WHERE artikeltyp=1 AND artikelid=bsa.id) AS min_gutschriftsnummer,
(SELECT if(count(gutschriftsnummer)>0,MAX(gutschriftsnummer),0) FROM gutschriften WHERE artikeltyp=1 AND artikelid=bsa.id) AS max_gutschriftsnummer,
(SELECT MIN(gutschriftsdatum) FROM gutschriften WHERE artikeltyp=1 AND artikelid=bsa.id) AS gutschriftsdatum,
(SELECT Anzahl FROM Rechnungen AS re WHERE re.Rechnungsnummer = 25519 AND ArtikelID=bsa.id and artikeltyp=1) AS Rechnungsanzahl,
(SELECT Anzahl FROM Gutschriften AS re WHERE re.Gutschriftsnummer = 25519 AND ArtikelID=bsa.id and artikeltyp=1) AS Gutschriftsanzahl

FROM bestellung_serviceartikel as bsa
JOIN Rechnungen AS re ON re.artikelid=bsa.id AND re.artikeltyp=1 AND re.rechnungsnummer=25519
WHERE auftragsID=‘15841’


ORDER BY Listenposition ASC
_

Es gibt das [ code ] und das [ quote ] Tag hier im Forum. Damit sehen die Postings gleich viel besser aus :wink:

Zum eigentlichen Problem: wieviele Ergebnisse liefert denn der Subselect, wenn du ihn einzeln ausführst?
Laut Anfrageplan sollte das bloß ein Ergebnis liefern, jedenfalls erwartet die Datenbank bloß ein Ergebnis.

Ich bin immer noch der Meinung, dass da irgendetwas anderes kaputt ist und die Datenbank bloß die Auswirkungen davon abbekommt. Kaputte Hardware oder kaputte Daten auf der Festplatte ist meine erste Annahme.

Das sollte man doch aber rausbekommen.

@ vogelpohl: Kannst du die Daten aus der Original-DB dumpen und auf einem komplett anderen Rechner (keine andere VM auf der selben Hardware) wieder einlesen. Auf diesem würde ich NUR das nackte Windows und PostgreSQL installieren. Wirklich nichts weiter. Und dann die Abfrage noch mal laufen lassen; dann können wir alle eine Ursache, nämlich Hardware oder OS, auschließen.

nick guter Ansatz.

ich werde es gleich mal testen…

Ich habe nun die gleiche pgVersion auf einem Server 2k installiert und den Dump eingespielt. Hat wunderbar geklappt und die Daten sind da. Führe ich aber die obige Abfrage aus, kracht es wieder.

staun
Hätte ich nicht gedacht…! Wie sich so etwas wohl unter *nix verhält?

@ads: Ist die Abfrage so etwas Besonderes?

Sorry, musste nochmal schnell was testen. hatte alten dump gewählt. Das ist der aktuelle Status.

W2000Server 32 Bit - 2Gb Ram - fail
W2003Server 32 Bit - 3Gb Ram - fail <- hier bräuchte ich die Abfrage
W2008Server 64 Bit - 4Gb Ram - fail

Welche Tests könnte ich noch durchführen

Was bedeutet *nix?

Ok, wie sieht das ganze auf einem beliebigen Unix/Linux Server aus?

Übliche Schreibweise für “irgend ein UNIX”. Also für irgend ein echtes Betriebssystem.

Andreas

Das werde ich gleich testen. Muss erstmal kurz ein System aufsetzen…

So, ich habe es jetzt auf einem Ubuntu-System getestet und es tritt der gleiche Fehler auf. Meine Konsole zeigt mir Fehler und die Db is down.
So komliziert ist die Abfrage doch garnicht?!

Was macht denn diese IF() Funktion?
Ist die selbst geschrieben?

castorp: IF ist in der SQL-Syntax enthalten.

vogelpohl: Kannst du einen minimalen Testcase erstellen, mit dem der Absturz auftritt? Also nur die im Query benötigten Tabellen samt Daten, plus die Anfrage.