Hallo,

ich arbeite in meinem Projekt viel mit Trigger und Functions. Dabei werden=

z.T. Funktionen durch die Trigger aufgerufen (perform ...)
Dabei stelle ich manchmal Probleme fest derart, dass falsche Berechnungen=

durchgeführt werden, da ein Trigger eine Funktion verwendet, die im Cache
liegt! Wenn ich die Funktion nur neu lade (create or replace.. ) wird trotz=
dem
die alte verwendet, wenn ich sie droppe und neu lade bekomme ich die
Fehlermeldung aus dem Betreff.
Meine Grundsätzliche Frage: Wo ist dieses verhalten (caching von Funktion=
en)
dokumentiert und kann man das beeinflussen ? Wann / Wie wird der cache
gelöscht ?

--
Mit freundlichen Grüßen
Rolf Schaufelberger

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

am Thu, dem 30.08.2007, um 12:00:00 +0200 mailte Rolf Schaufelberger fol=
gendes:
> Hallo,
>
> ich arbeite in meinem Projekt viel mit Trigger und Functions. Dabei wer=
den
> z.T. Funktionen durch die Trigger aufgerufen (perform ...)
> Dabei stelle ich manchmal Probleme fest derart, dass falsche Berechnung=
en
> durchgeführt werden, da ein Trigger eine Funktion verwendet, die im C=
ache

Wohl eher das Ergebniss der Funktion, oder? Hast Du die als IMMUTABLE
definiert, und sie ist es nicht?


> Meine Grundsätzliche Frage: Wo ist dieses verhalten (caching von Funk=
tionen)
> dokumentiert und kann man das beeinflussen ? Wann / Wie wird der cache
> gelöscht ?

Ich tippe auf
http://www.postgresql.org/docs/current/static/xfunc-volatili ty.html


Andreas
--
Andreas Kretschmer
Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: -> Header)
GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo [at] postgresql.org so that your
message can get through to the mailing list cleanly

Am Donnerstag, 30. August 2007 12:00 schrieb Rolf Schaufelberger:
> Meine Grundsätzliche Frage: Wo ist dieses verhalten (caching von
> Funktionen) dokumentiert und kann man das beeinflussen ? Wann / Wie wir=
d
> der cache gelöscht ?

Es gibt keine Cache für Funktionen. Da müsste man schon man ein konkr=
eteres
Beispiel sehen, um zu erkennen, warum es nicht funktioniert.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Hallo,

On Donnerstag 30 August 2007, A. Kretschmer wrote:
> am Thu, dem 30.08.2007, um 12:00:00 +0200 mailte Rolf Schaufelberger
folgendes:
> > Hallo,
> >
> > ich arbeite in meinem Projekt viel mit Trigger und Functions. Dabei
> > werden z.T. Funktionen durch die Trigger aufgerufen (perform ...)
> > Dabei stelle ich manchmal Probleme fest derart, dass falsche Berechnung=
en
> > durchgeführt werden, da ein Trigger eine Funktion verwendet, die im C=
ache
>
> Wohl eher das Ergebniss der Funktion, oder? Hast Du die als IMMUTABLE
> definiert, und sie ist es nicht?

Hatte erst mal nicht angegeben, war dann VOLATILE, dann habe ich STABLE
angegeben, Ergebnis beidesmal gleich falsch.

>
> > Meine Grundsätzliche Frage: Wo ist dieses verhalten (caching von
> > Funktionen) dokumentiert und kann man das beeinflussen ? Wann / Wie wird
> > der cache gelöscht ?
>
> Ich tippe auf
> http://www.postgresql.org/docs/current/static/xfunc-volatili ty.html
Habe ich in der Zwischenzeit auch gefunden, aber es heißt dort ausdrück=
lich,
"within a single statement". Es sollte als in beiden Fällen das richtige=

Ergebnis liefern, wenn es mit dem gleichen Parameter aufgerufen wird.
Der Ablauf ist etwa so:

Trigger T
ruft Funktion A ( param)
ruft Funktion B ( param)
ruft Funktion C ( param)

(C ist die F. welche das falsche Ergenis liefert.=09
Wenn ich Funktion A ( param) direkt aufrufe, ist das Ergebnis falsch,
Rufe ich B oder C direkt auf, ist es richtig.
Function C ist eine einfache SQL-Funktion (langauge SQL), A und B sind in=

plsql geschrieben.
Ich habe auch alle drei Funktionen gedroppt, neu geladen, Ergebnis immer no=
ch
falsch. Bin ratlos.

Rolf Schaufelberger

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

am Thu, dem 30.08.2007, um 13:24:53 +0200 mailte Peter Eisentraut folgen=
des:
> Am Donnerstag, 30. August 2007 12:00 schrieb Rolf Schaufelberger:
> > Meine Grundsätzliche Frage: Wo ist dieses verhalten (caching von
> > Funktionen) dokumentiert und kann man das beeinflussen ? Wann / Wie w=
ird
> > der cache gelöscht ?
>
> Es gibt keine Cache für Funktionen. Da müsste man schon man ein kon=
kreteres

Ausführungspläne?


> Beispiel sehen, um zu erkennen, warum es nicht funktioniert.

ACK.


Andreas
--
Andreas Kretschmer
Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: -> Header)
GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

On Donnerstag 30 August 2007, Peter Eisentraut wrote:
> Am Donnerstag, 30. August 2007 12:00 schrieb Rolf Schaufelberger:
> > Meine Grundsätzliche Frage: Wo ist dieses verhalten (caching von
> > Funktionen) dokumentiert und kann man das beeinflussen ? Wann / Wie wird
> > der cache gelöscht ?
>
> Es gibt keine Cache für Funktionen. Da müsste man schon man ein konkr=
eteres
> Beispiel sehen, um zu erkennen, warum es nicht funktioniert.

anbei mal die DEBUG Ausgabe. Sie auch vorherigen antwort an a.Kretschmar.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
select calculate_preis(832);
NOTICE: Custid =3D 20002, Currencyid =3D 1 , Country=3D DE, Discount =3D 0
KONTEXT: SQL statement "SELECT calculate_preis( $1 , $2 )"
PL/pgSQL function "calculate_preis" line 7 at perform
NOTICE: Search price for item 2735 article 58
KONTEXT: SQL statement "SELECT calculate_preis( $1 , $2 )"
PL/pgSQL function "calculate_preis" line 7 at perform
NOTICE: No article_price_id
KONTEXT: PL/pgSQL function "calculate_preis" line 68 at assignment
SQL statement "SELECT calculate_preis( $1 , $2 )"
PL/pgSQL function "calculate_preis" line 7 at perform
NOTICE: Search price for item 2736 article 59
KONTEXT: SQL statement "SELECT calculate_preis( $1 , $2 )"
PL/pgSQL function "calculate_preis" line 7 at perform
NOTICE: Search company price
KONTEXT: PL/pgSQL function "calculate_preis" line 68 at assignment
SQL statement "SELECT calculate_preis( $1 , $2 )"
PL/pgSQL function "calculate_preis" line 7 at perform
NOTICE: Search licence price
KONTEXT: PL/pgSQL function "calculate_preis" line 68 at assignment
SQL statement "SELECT calculate_preis( $1 , $2 )"
PL/pgSQL function "calculate_preis" line 7 at perform
NOTICE: Search common price
KONTEXT: PL/pgSQL function "calculate_preis" line 68 at assignment
SQL statement "SELECT calculate_preis( $1 , $2 )"
PL/pgSQL function "calculate_preis" line 7 at perform
NOTICE: Updating 2736 to price 995
KONTEXT: SQL statement "SELECT calculate_preis( $1 , $2 )"
PL/pgSQL function "calculate_preis" line 7 at perform
NOTICE: Search price for item 2737 article 42
KONTEXT: SQL statement "SELECT calculate_preis( $1 , $2 )"
PL/pgSQL function "calculate_preis" line 7 at perform
NOTICE: Updating 2737 to price -99
KONTEXT: SQL statement "SELECT calculate_preis( $1 , $2 )"
PL/pgSQL function "calculate_preis" line 7 at perform
SQL statement "SELECT calculate_preis( $1 , $2 )"
PL/pgSQL function "calculate_preis" line 7 at perform
NOTICE: Add_bonus: Found item 101, value=3D10 type=3DPERC_ALL <=3D=3D=3D=
=3D
KONTEXT: SQL statement "SELECT add_bonus( $1 )"
PL/pgSQL function "calculate_preis" line 106 at perform
SQL statement "SELECT calculate_preis( $1 , $2 )"
PL/pgSQL function "calculate_preis" line 7 at perform
NOTICE: gesamtpreis =3D 0 =
<=3D=3D=3D=3D
KONTEXT: SQL statement "SELECT add_bonus( $1 )"
PL/pgSQL function "calculate_preis" line 106 at perform
SQL statement "SELECT calculate_preis( $1 , $2 )"
PL/pgSQL function "calculate_preis" line 7 at perform
NOTICE: add_bonus: set preis to 0 <=3D=3D=
=3D=3D
KONTEXT: SQL statement "SELECT add_bonus( $1 )"
PL/pgSQL function "calculate_preis" line 106 at perform
SQL statement "SELECT calculate_preis( $1 , $2 )"
PL/pgSQL function "calculate_preis" line 7 at perform
NOTICE: Updating pay_order to 1525
KONTEXT: SQL statement "SELECT calculate_preis( $1 , $2 )"
PL/pgSQL function "calculate_preis" line 7 at perform
NOTICE: Updating bilder_item 2735 to 995
KONTEXT: SQL statement "SELECT calculate_preis( $1 , $2 )"
PL/pgSQL function "calculate_preis" line 7 at perform
calculate_preis
-----------------

(1 Zeile)

pgp=3D#

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D
Man beachte die Zeilen die ich mit <=3D=3D=3D=3D markiert habe.
Es geht um die Funktion add_bonus.

und dann:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D
pgp=3D# select add_bonus(832);
NOTICE: Add_bonus: Found item 101, value=3D10 type=3DPERC_ALL
NOTICE: gesamtpreis =3D 995
NOTICE: add_bonus: set preis to 99
add_bonus
-----------

(1 Zeile)

pgp=3D#
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D
bzw :

pgp=3D# select gesamtpreis(832);
gesamtpreis
-------------
995
(1 Zeile)

pgp=3D#
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
calculate_preis ruft add_bonus und diese gesamtpreis


--
Rolf Schaufelberger

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo [at] postgresql.org so that your
message can get through to the mailing list cleanly

> Ausführungspläne?
>

explain select calculate_preis(832);
QUERY PLAN
------------------------------------------
Result (cost=3D0.00..0.01 rows=3D1 width=3D0)
(1 Zeile)

Rolf

---------------------------(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

A. Kretschmer wrote:
> am Thu, dem 30.08.2007, um 13:24:53 +0200 mailte Peter Eisentraut folgen=
des:
>> Am Donnerstag, 30. August 2007 12:00 schrieb Rolf Schaufelberger:
>>> Meine Grundsätzliche Frage: Wo ist dieses verhalten (caching von
>>> Funktionen) dokumentiert und kann man das beeinflussen ? Wann / Wie wird
>>> der cache gelöscht ?
>> Es gibt keine Cache für Funktionen. Da müsste man schon man ein konk=
reteres
>
> Ausführungspläne?

ja - bei plpgsql funktionen werden die Ausführungspläne auf einer
per-session bassis gecached aber alle Versionen VOR 8.3 haben keine
automatische Invalidierung der Pläne bei =C4nderung was zu den
beschriebenen Problemem führen kann.
Die einzige Lösung hierbei ist ein disconnect/reconnect im client.


Stefan


---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

am Thu, dem 30.08.2007, um 13:38:38 +0200 mailte Rolf Schaufelberger fol=
gendes:
>
> > Ausführungspläne?
> >
>
> explain select calculate_preis(832);

Eh, das bezog sich auf Peters Aussage, es gäbe keinen Cache. Es werden
aber die Pläne gecached, was manchmal zu Seiteneffekten führen kann.
Siehe auch Stephans Antwort.


Andreas
--
Andreas Kretschmer
Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: -> Header)
GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Am Donnerstag, 30. August 2007 13:30 schrieb A. Kretschmer:
> > Es gibt keine Cache für Funktionen. Da müsste man schon man ein
> > konkreteres
>
> Ausführungspläne?

Aber nicht wenn er PERFORM verwendet, was er angedeutet hatte.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Ok,
ich glaube ich kann Entwarnung geben:
Der Berechnungsfehler hier kommt tatsächlich durch einen Fehler von mir=

zustande. Ich war nur wegen des Problems, dass eine aktualisierte Funktion=

nicht verwendet wurde, auf dem falschen Pfad bei der Problemsuche. Letztere=
s
Problem kann ich durch ein/ausloggen beheben (bzw dann apache restart).

Rolf Schaufelberger

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Peter Eisentraut wrote:
> Am Donnerstag, 30. August 2007 13:30 schrieb A. Kretschmer:
>>> Es gibt keine Cache für Funktionen. Da müsste man schon man ein
>>> konkreteres
>> Ausführungspläne?
>
> Aber nicht wenn er PERFORM verwendet, was er angedeutet hatte.

s/PERFORM/EXECUTE ?


Stefan


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Rolf Schaufelberger schrieb:
> ich arbeite in meinem Projekt viel mit Trigger und Functions.
> Dabei werden z.T. Funktionen durch die Trigger
> aufgerufen (perform ...)
> Dabei stelle ich manchmal Probleme fest derart, dass
> falsche Berechnungen durchgeführt werden, da ein Trigger
> eine Funktion verwendet, die im Cache liegt! Wenn ich
> die Funktion nur neu lade (create or replace.. ) wird
> trotzdem die alte verwendet, wenn ich sie droppe und
> neu lade bekomme ich die Fehlermeldung aus dem Betreff.
> Meine Grundsätzliche Frage: Wo ist dieses verhalten
> (caching von Funktionen) dokumentiert und kann man das
> beeinflussen ? Wann / Wie wird der cache gelöscht ?

Wahrscheinlich verstehe ich das falsch, aber sowas kann's
eigentlich nicht geben. Siehe folgendes Beispiel:

CREATE TABLE test(id integer PRIMARY KEY);

CREATE OR REPLACE FUNCTION tr() RETURNS trigger
LANGUAGE plpgsql VOLATILE AS
$$BEGIN
RAISE NOTICE 'Erste Version, aufgerufen mit %', NEW.id;
RETURN NULL;
END;$$;

CREATE TRIGGER test_i AFTER INSERT ON test FOR EACH ROW
EXECUTE PROCEDURE tr();

INSERT INTO test(id) VALUES (42);
NOTICE: Erste Version, aufgerufen mit 42

SELECT oid FROM pg_proc WHERE proname=3D'tr';
oid
-------
45834
(1 row)

CREATE OR REPLACE FUNCTION tr() RETURNS trigger
LANGUAGE plpgsql VOLATILE AS
$$BEGIN
RAISE NOTICE 'Zweite Version, aufgerufen mit %', NEW.id;
RETURN NULL;
END;$$;

INSERT INTO test(id) VALUES (-1);
NOTICE: Zweite Version, aufgerufen mit -1

SELECT oid FROM pg_proc WHERE proname=3D'tr';
oid
-------
45834
(1 row)


Funktionen werden einfach ersetzt, und die OID ändert
sich nicht. Das heißt, auch ein Statement, das bereits
vor dem Ersetzen der Funktion ausgeführt wurde und nachher
wiederverwendet wird (in einer PL/pgSQL-Funktion z.B.),
wird die geänderte Funktion verwenden.
Im Ausführungsplan werden Objekte über OID referenziert.

Liebe Grüße,
Laurenz Albe

---------------------------(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

Rolf Schaufelberger schrieb:

> Der Ablauf ist etwa so:
>
> Trigger T
> ruft Funktion A ( param)
> ruft Funktion B ( param)
> ruft Funktion C ( param)
>
> (C ist die F. welche das falsche Ergenis liefert.=09
> Wenn ich Funktion A ( param) direkt aufrufe, ist das
> Ergebnis falsch,
> Rufe ich B oder C direkt auf, ist es richtig.
> Function C ist eine einfache SQL-Funktion (langauge SQL), A
> und B sind in
> plsql geschrieben.
> Ich habe auch alle drei Funktionen gedroppt, neu geladen,
> Ergebnis immer noch
> falsch. Bin ratlos.

Ich glaub's noch immer nicht.

Super wäre ein (vereinfachtes) Code-Beispiel, mit dem
man das Problem nachvollziehen kann.

Laurenz Albe

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

On Donnerstag 30 August 2007, Albe Laurenz wrote:
> Rolf Schaufelberger schrieb:
> > Der Ablauf ist etwa so:
> >
> > Trigger T
> > ruft Funktion A ( param)
> > ruft Funktion B ( param)
> > ruft Funktion C ( param)
> >
> > (C ist die F. welche das falsche Ergenis liefert.
> > Wenn ich Funktion A ( param) direkt aufrufe, ist das
> > Ergebnis falsch,
> > Rufe ich B oder C direkt auf, ist es richtig.
> > Function C ist eine einfache SQL-Funktion (langauge SQL), A
> > und B sind in
> > plsql geschrieben.
> > Ich habe auch alle drei Funktionen gedroppt, neu geladen,
> > Ergebnis immer noch
> > falsch. Bin ratlos.
>
> Ich glaub's noch immer nicht.
>
> Super wäre ein (vereinfachtes) Code-Beispiel, mit dem
> man das Problem nachvollziehen kann.
>
> Laurenz Albe
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
Ja, ja, hatte doch geschrieben, dass der Fehler in der ersten Funktion lag.

Da ich aber schon mal das Problem hatte, dass eine falsche Funktion aufgeru=
fen
wurde und wegen der Fehlermeldung mit dem cache hatte ich in der falschen=

Richtung gesucht.
Das erwähnte Problem mit der falschen Funktion funktionjiert folgenderma=
ßen;

Ich habe die Schema: special1, special2, common,
und die Funktionen: special1.ftest, special2.ftest, common.master
common.master ruft dann : perform ftest();
und soll je nach search_path mal die eine mal die andere aufrufen.
Wenn ich nun folgendes mache:
set search_path to special1, common;
select common.master();
set search_path to special2, common;
select common.master();

wird beides mal special1.ftest aufgerufen!
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
CREATE schema special1;
CREATE schema special2;
CREATE schema common;

CREATE OR REPLACE FUNCTION special1.ftest() RETURNS void
LANGUAGE plpgsql VOLATILE AS
$$BEGIN
raise notice 'Special 1';
return;
END;$$;

CREATE OR REPLACE FUNCTION special2.ftest() RETURNS void
LANGUAGE plpgsql VOLATILE AS
$$BEGIN
raise notice 'Special 2';
return;
END;$$;

CREATE OR REPLACE FUNCTION common.master() RETURNS void
LANGUAGE plpgsql VOLATILE AS
$$BEGIN
RAISE NOTICE 'Common Master';
perform ftest();=09
RETURN;
END;$$;

SET search_path to special1, common;
SELECT common.master();

SET search_path to special2, common;
SELECT common.master();
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D
liefert bei mir:
SET
psql:workspace/trunk/sql/xx.sql:29: NOTICE: Common Master
psql:workspace/trunk/sql/xx.sql:29: NOTICE: Special 1
KONTEXT: SQL statement "SELECT ftest()"
PL/pgSQL function "master" line 3 at perform
master
--------

(1 Zeile)

SET
psql:workspace/trunk/sql/xx.sql:32: NOTICE: Common Master
psql:workspace/trunk/sql/xx.sql:32: NOTICE: Special 1
KONTEXT: SQL statement "SELECT ftest()"
PL/pgSQL function "master" line 3 at perform

Uups !!!


Rolf Schaufelberger

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Rolf Schaufelberger schrieb:
> Das erwähnte Problem mit der falschen Funktion funktionjiert
> folgendermaßen;

Danke für die Erklärung, jetzt versteh ich's auch.

Laurenz Albe

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org