Re: SIGSEGV when trying to start in single user mode
От | Björn Häuser |
---|---|
Тема | Re: SIGSEGV when trying to start in single user mode |
Дата | |
Msg-id | e8a218660909191141m4738f6e8u8c1cfb2999d9fb@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: SIGSEGV when trying to start in single user mode (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-general |
Hello Tom, thank you for your help. I resetted the xlog and the server started again. Regards, Björn 2009/9/19 Tom Lane <tgl@sss.pgh.pa.us>: > =?UTF-8?B?QmrDtnJuIEjDpHVzZXI=?= <bjoernhaeuser@googlemail.com> writes: >> I have a problem with my PostgreSQL 8.3.4 installation. > >> We had some problems with our storage subsystem and it seems >> postgresql suffered a little bit from it. >> Here are some log excerpts: > >> # /etc/init.d/postgresql-8.3 start >> Starting PostgreSQL 8.3 database server: main* Removed stale pid file. > > You really need to get rid of that startup script, or at least get rid > of the part of it that thinks it should remove the postmaster's PID > file. That's completely unsafe and poor practice. (I doubt it's > related to your immediate problem, though.) > >> 2009-09-19 16:51:00 CEST PANIC: right sibling's left-link doesn't >> match: block 49696 links to 49978 instead of expected 3 in index >> "132010" >> 2009-09-19 16:51:00 CEST LOG: startup process (PID 3727) was >> terminated by signal 6: Aborted > > Ugh, so you have a corrupted index that is touched by the unreplayed > WAL sequence. I'm afraid the only easy way out of this is to use > pg_resetxlog, which is a bit risky since you'll lose whatever other > changes haven't been applied to the database. Probably the safest > thing to do is pg_resetxlog, start up, dump everything, initdb, > reload. > >> But when I tried to start Postgresql in single-user mode to be able to >> repair this index i am getting the mentioned SIGSEGV. > > Hmm, that's a bug, but even if it weren't broken it would not help you. > A single-user backend still has to replay any unreplayed WAL, so it > would still hit the PANIC. > > regards, tom lane >
В списке pgsql-general по дате отправления: