PostgreSQL+PHP -Fragen zu Timeout
am 09.12.2005 16:09:13 von Horst Schmidt
Hallo Newsgroups,
ich möchte bestimmte Select und Update-Anweisungen nach einer bestimmten
Zeit abgebrochen haben.
Die Timeout-Angabe habe ich jedoch nur bei PG_CONNECT (Schlüsselwort
connect_timeout) gefunden (wobei kein Timeout stattfindet bzw. ich habe
keins hinbekommen).
Hat jemand eine Idee, wie ich _einer_ Abfrage z.B. ein Timeout von 10
Sek. zuweisen kann (Linux, Apache 1.3.33, PHP4.3.11, PostgreSQL8.03)?
Besten Dank,
Horst
Re: PostgreSQL+PHP -Fragen zu Timeout
am 11.12.2005 19:20:37 von Christian Haase
> ich möchte bestimmte Select und Update-Anweisungen nach einer bestimmten
> Zeit abgebrochen haben.
> Die Timeout-Angabe habe ich jedoch nur bei PG_CONNECT (Schlüsselwort
> connect_timeout) gefunden (wobei kein Timeout stattfindet bzw. ich habe
> keins hinbekommen).
> Hat jemand eine Idee, wie ich _einer_ Abfrage z.B. ein Timeout von 10
> Sek. zuweisen kann (Linux, Apache 1.3.33, PHP4.3.11, PostgreSQL8.03)?
BEGIN;
SET LOCAL statement_timeout = 5000; (zeit in milliseconds)
SELECT * FROM table;
COMMIT;
ciao
chris
--
Christian Haase http://www.haase.net
Re: PostgreSQL+PHP -Fragen zu Timeout
am 13.12.2005 21:05:27 von Horst Schmidt
Christian Haase wrote:
> BEGIN;
> SET LOCAL statement_timeout = 5000; (zeit in milliseconds)
> SELECT * FROM table;
> COMMIT;
Hallo Chris,
danke für die schnelle Antwort. Hat leider ein bisschen gedauert, bis
ich Deinen Ratschlag testen konnte. Leider funktioniert es nicht so,
wie ich mir das vorstelle. Ich werde mal mein Problem näher erläutern:
# 1. Abfrage # begin;
# 1. Abfrage # lock table
# 1. Abfrage # select * from where id='SC' limit 1;
# 1. Abfrage # !!!!! kein Commit
# 2. Abfrage # begin;
# 2. Abfrage # set local statement_timeout = 5000;
# 2. Abfrage # lock table ;
# 2. Abfrage # select * from where id='SC' limit 1;
# 2. Abfrage # update set name='Santa Claus' where id='SC';
# 2. Abfrage # commit;
# es vergehen mehr als 5000 ms, 2. Abfrage wird nicht abgebrochen
# 1. Abfrage # commit;
Hintergrund: Während die 1. Anweisung läuft, soll die 2. Anweisung den
selektierten Datensatz der 1. Anweisung WEDER schreiben NOCH lesen
dürfen (habe mich darum für lock table entschieden - vielleicht gibt es
hierfür auch eine elegantere Lösung). Funktioniert soweit ganz gut,
jedoch soll die 2. Abfrage abgebrochen werden, falls die 1. Abfrage mal
nicht so schnell zum commit kommt.
Vielleicht hast Du ja noch eine Idee. Danke schonmal.
Gruß,
Horst
Re: PostgreSQL+PHP -Fragen zu Timeout
am 14.12.2005 12:01:51 von Andreas Froede
Horst Schmidt wrote:
> Hintergrund: Während die 1. Anweisung läuft, soll die 2. Anweisung den
> selektierten Datensatz der 1. Anweisung WEDER schreiben NOCH lesen
> dürfen
man Isolation Level
CIAO
andreas
--
Klettern in Thüringen: http://www.climb.spider-net.de
Kletterhalle in Jena: http://www.wand.spider-net.de
Re: PostgreSQL+PHP -Fragen zu Timeout
am 14.12.2005 12:52:02 von Horst Schmidt
Andreas Froede wrote:
> man Isolation Level
>
>
> CIAO
> andreas
Hallo Andreas,
besten Dank, doch "set transaction isolation level serializable" ist
gesetzt, im Beispiel nur nicht mit aufgeführt, da es keine Änderung
bzgl. des Timeouts bewirkt.
Danke und viele Grüße,
Horst
Re: PostgreSQL+PHP -Fragen zu Timeout
am 15.12.2005 10:12:02 von Andreas Froede
Horst Schmidt wrote:
> Andreas Froede wrote:
> > man Isolation Level
> besten Dank, doch "set transaction isolation level serializable" ist
Und warum lockst Du dann die Tabelle?
CIAO
andreas
--
Klettern in Thüringen: http://www.climb.spider-net.de
Kletterhalle in Jena: http://www.wand.spider-net.de
Re: PostgreSQL+PHP -Fragen zu Timeout
am 16.12.2005 12:36:25 von Horst Schmidt
Andreas Froede wrote:
>> besten Dank, doch "set transaction isolation level serializable" ist
> Und warum lockst Du dann die Tabelle?
Ich Unwissender habe leider noch keine Möglichkeit gefunden, durch
Einleiten einer Transaktion auch das LESEN eines 2. Clients zu
unterbinden (Schreibzugriff unterbinden ist nicht das Problem). Daher
ein lock table. Ist unelegant, doch ich weiß mir nicht besser zu
helfen. Ist noch eine andere Problemstellung als das "Timeout", doch
vielleicht hast Du 'ne Idee?
Viele Dank und Gruß,
Horst