I am running postgresql 8.3, I was not aware of the 3 options (smart, fast, or immediate). So it used the default - "fast". The state of the server when I sent this e-mail was that there were two remaining connections/postgres subprocesses. I used kill -9 to stop those two subprocesses. Then postgres was able to stop normally. After that, I restarted postgresql normally and it went into recovery mode for about 30 seconds. After that, it started to behave normally again. On Fri, Jun 20, 2008 at 9:34 PM, Scott Marlowe <scott.marlowe@xxxxxxxxx> wrote: > On Fri, Jun 20, 2008 at 7:12 PM, John Cheng <chonger.cheng@xxxxxxxxx> wrote: >> We had a run away process on our database box that used up all the >> physical and all the virtual memory (swap). This caused the RedHat >> Linux oom-killer to kill many processes, including some Postgres ones. >> Postgres went into a funky state after that time: > > SNIP > >> I think the fact that a process used up all the available memory >> (physical and virtual) caused Postgres to go into a weird state. Now >> it will not respond to kill, or pg_ctl for shutdown. Would the right >> thing to do be using kill -9 to stop the server? > > When you say it won't respond to pg_ctl for shutdown, have you tried > the three options for the -m switch in order? Are you running a > pretty recent pg version? Which one? > -- - John L Cheng
