Tom Lane wrote:
Ok, you wrote "Postgres will recover automatically", but could this take
several minutes?
Yeah, potentially. I don't suppose you have any idea how long it'd been
since your last checkpoint, but what do you have checkpoint_timeout and
checkpoint_segments set to?
I did not change these parameters from their default values, so
checkpoint_timeout is 5 min and checkpoint_segments is 8.
What I'd like to know about is why the child process was unresponsive to
SIGINT in the first place. There's little we can do about long-running
plpython functions, for instance, but if it was looping in Postgres
proper then we should do something about that. Can you reproduce this
problem easily?
Unfortunately not. I have tried the same query and it took only about 1
sec to complete. In fact, it's a simple seq scan with a single filter
condition. No user defined functions are involved.
Maybe it has something to do with the users connecting from their
Windows machines to the PostgreSQL server using psqlodbc. On the other
hand, it has not been the first time that such a user connection had to
be terminated and we did never experience this problem.
If I see the phenomenon again I will use strace or something similar to
find out what the backend process is doing.
Regards,
Christian
--
Deriva GmbH Tel.: +49 551 489500-42
Financial IT and Consulting Fax: +49 551 489500-91
Hans-Böckler-Straße 2 http://www.deriva.de
D-37079 Göttingen
Deriva CA Certificate: http://www.deriva.de/deriva-ca.cer
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org/
