[GENERAL] recovery mode
Hi all, my database entered in recovery mode last week, analyzing log file of server found this error: cat /var/log/menssages kernel: postmaster[1023]: segfault at fff0 rip 0060d993 rsp 7fff15f53c28 error 4 which means that? att Paul Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbuscados.yahoo.com
[GENERAL] recovery mode
Hi all, my database entered in recovery mode last week, analyzing log file of server found this error: cat /var/log/menssages kernel: postmaster[1023]: segfault at fff0 rip 0060d993 rsp 7fff15f53c28 error 4 which means that? att Paul Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbuscados.yahoo.com
Re: [GENERAL] recovery mode
paulo matadr saddon...@yahoo.com.br writes: analyzing log file of server found this error: cat /var/log/menssages kernel: postmaster[1023]: segfault at fff0 rip 0060d993 rsp 7fff15f53c28 error 4 which means that? Well, it's a crash, but there's not nearly enough information here to say what caused it. Do you have a core-dump file you could get a stack trace from? regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Recovery mode
Hi there, Just noticed this in my webapp logs: ERROR: FATAL: the database system is in recovery mode Only one instance, so I'm not too concerned, but why, how often, how long for, etc. Am I negelecting to do some important database maintenace? Could it be related to the backup cron performs hourly: pg_dump --format=custom --file=file db Seb -- Emacs' AlsaPlayer - Music Without Jolts Lightweight, full-featured and mindful of your idyllic happiness. http://home.gna.org/eap -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] recovery mode
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. I believe that it was a backend that I tried -9'ing. I knew it wasn't something that good to do, but I had to get it running again. It's amazing how bold you get when you hear an entire department mumbling about "Why isn't the site working?". : ) Anyway, I think the problem wasn't in postgres. I rebooted the machine, and it worked - for about ten minutes. Then, it froze, with the kernel crapping out. I rebooted it, it lasted about three minutes until the same thing happened. Reboot, it didn't even get through the fsck before it did it again. I looked at the CPU temps, one of the four was warmer than it should be, but still within acceptable limits (40 C). So, I shut it down, reseated the RAM chassis, the DIMM's, the CPU's, and the expansion cards. When it came up, I compiled and put on a newer kernel (I guess there was some good in the crashes), and then it worked fine. Because of the symptoms, I imagine that it was a flakey connection. Odd, considering that everything except the DIMM's (including the CPU's) are literally screwed to the motherboard! steve
