From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Steve Wolfe" <steve(at)iboats(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: "recovery mode" |
Date: | 2001-01-23 05:39:19 |
Message-ID: | 5330.980228359@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Steve Wolfe" <steve(at)iboats(dot)com> writes:
> What exactly is "recovery mode"? Today, the backend went into recovery
> mode, and simply wouldn't do anything. Not using any CPU, and would not go
> away even with a kill -9. I ended up having to reboot the machine to get
> the database working again....
I don't think recovery mode actually does much in 7.0.* --- I think it's
just a stub (Vadim might know better though). In 7.1 it means the thing
is replaying the WAL log after a crash. In any case it shouldn't
create a lockup condition like that.
The only cases I've ever heard of where a user process couldn't be
killed with kill -9 are where it's stuck in a kernel call (and the
kill response is being held off till the end of the kernel call).
Any such situation is arguably a kernel bug, of course, but that's
not a lot of comfort.
Exactly which process were you sending kill -9 to, anyway? There should
have been a postmaster and one backend running the recovery-mode code.
If the postmaster was responding to connection requests with an error
message, then I would not say that it was locked up.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert B. Easter | 2001-01-23 07:07:55 | Re: Data entry screen building utilities |
Previous Message | Bruce Momjian | 2001-01-23 04:47:40 | Re: PL/Python (was: Re: [GENERAL] Re: Trigger) |