On 10/31/07, Christian Schröder <cs@xxxxxxxxx> wrote:
> 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.
Tom, is it possible the backend was doing something that couldn't be
immediately interrupted, like a long wait on IO or something?
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org/
