Re: PostgreSQL 7.4.1: Transaktionsproblem

Hallo,

aha, da wir parallel noch mit der libpq-Schnittstelle arbeiten, müssen wir
das AUTOCOMMIT setzen.
Ich wollte nun mal das Beispiel so hinbekommen, dass ein ROLLBACK den Cursor
schließt, um unsere Anwendung dann sukzessive vergleichen zu können. Da hat
mir Deine Aussage mit dem DECLARE CURSOR nach dem BEGIN zum Verständnis sehr
geholfen, dass ich es nun hinbekomme, dass ein ROLLBACK den Cursor schließt:

EXEC SQL AT :PSQL_connect SET AUTOCOMMIT TO ON;
EXEC SQL BEGIN;
EXEC SQL at :PSQL_connect DECLARE c_testdb CURSOR WITH HOLD FOR
SELECT nummer_id,nummer from test2db where nummer_id > 0
order by nummer_id;
[...]

EXEC SQL AT :PSQL_connect update test2db set nummer
= :nummer where nummer_id = :ID;
lerror = sqlca.sqlcode;
fprintf(stderr,"update sqlcode:
%ld\n",sqlca.sqlcode);

if ((ID == 1) || (ID == 6)) {
EXEC SQL ROLLBACK;
} else {
EXEC SQL COMMIT;
}
EXEC SQL BEGIN;
EXEC SQL AT :PSQL_connect fetch c_testdb into
[...]

Wichtig war hier, dass dass Rollback tatsächlich nach dem ersten BEGIN
kommt, welches kurz vor dem DECLARE steht. Daher habe ich die If Abfrage auf
ID == 1 geändert, dann wird der Cursor auch tatsächlich geschlossen. Bei der
ursprünglichen ID == 3 nicht, da hier ja schon wieder nach den DECLARE ein
Commit kam (was ja nun den Cursor nicht schließt und anschließend eine neue
Transaktion geöffnet wird.

D.h. also bei den beiden nachfolgenden zwei Beispielen vereinfacht
dargstellt

A)
DECLARE CURSOR ...
BEGIN WORK
...
ROLLBACK WORK

B)
BEGIN WORK
DECLARE CURSOR ...
...
ROLLBACK WORK

dass im Beispiel A) der Cursor überlebt, im Beispiel B) nicht. Vorrausetzung
ist, dass AUTOCOMMIT gesetzt ist, da sonst die Transaktion im Beispiel A)
beim DECLARE geöffnet wird und das nachfolgende nochmal eine Transktion zu
öffnen versucht (es kommt auch ene Fehlermeldung: "there is already a
transaction in progress".

Eine Möglichkeit festzulegen, dass im Beispiel B) der Cursor doch übelebt
gebt es wohl nicht, oder? Ich frage deshalb so naiv, weil es ja mit dem
AUTOCOMMIT-Schalter auch möglich ist, die Transaktionssteuerung entscheidend
zu beeinflussen.

Gruß
Lars Denkewitz

-----Ursprüngliche Nachricht-----
Von: Andreas Seltenreich [mailto:seltenreich(at)gmx(dot)de]
Gesendet: Donnerstag, 11. August 2005 19:23
An: Denkewitz Lars
Cc: pgsql-de-allgemein(at)postgresql(dot)org
Betreff: Re: [pgsql-de-allgemein] PostgreSQL 7.4.1: Transaktionsproblem

Denkewitz Lars schrob:

[...]
> EXEC SQL AT :PSQL_connect SET AUTOCOMMIT TO ON;
>
> EXEC SQL at :PSQL_connect DECLARE c_testdb CURSOR WITH HOLD FOR
> SELECT nummer_id,nummer from test2db where nummer_id > 0
> order by nummer_id;
[...]
> EXEC SQL BEGIN;
>
> EXEC SQL AT :PSQL_connect update test2db set nummer
> = :nummer where nummer_id = :ID;
> lerror = sqlca.sqlcode;
> fprintf(stderr,"update sqlcode:
> %ld\n",sqlca.sqlcode);
>
> if ((ID == 3) || (ID == 6)) {
> EXEC SQL ROLLBACK;
> } else {
> EXEC SQL COMMIT;
> }
> EXEC SQL AT :PSQL_connect fetch c_testdb into
[...]

> D.h. dass bei den Nummern 3 und 6 zunächst der Satz geupdatet wurde, dass
> Rollback gezogen und anschließend mit dem WITH HOLD Cursor weitergefetcht
> werden konnte.

Das Verhalten im obigen Beispiel ist aber durchaus mit dem Standard
vereinbar, da der Cursor ja in einer eigenen, durch das SET AUTOCOMMIT
TO ON impliziert committeten Transaktion erstellt wurde.

Relevant für den holdable cursor wäre ein ROLLBACK nur, wenn die
Transaktion, in der der cursor erstellt wurde, zurückgerollt werden
würde.

Gruß
Andreas

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match