Обсуждение: postgres will not start up - corrupted on restart
I'm running postgresql 9.0.
I was running several processes and did "sudo service postgres restart" and it has thrown a fit.
2012-02-24 12:45:13 PST:[local]:[unknown]@[unknown]:[16969]: LOG: incomplete startup packet
2012-02-24 12:45:13 PST::@:[16968]: LOG: database system was not properly shut down; automatic recovery in progress
2012-02-24 12:45:13 PST::@:[16968]: LOG: consistent recovery state reached at 35E/C009D2B0
2012-02-24 12:45:13 PST::@:[16968]: LOG: redo starts at 35E/8503C678
2012-02-24 12:45:13 PST::@:[16968]: PANIC: GIN metapage disappeared
2012-02-24 12:45:13 PST::@:[16968]: CONTEXT: xlog redo Update metapage, node: 1663/16558714/114537692 blkno: 85
2012-02-24 12:45:13 PST::@:[16967]: LOG: startup process (PID 16968) was terminated by signal 6: Aborted
2012-02-24 12:45:13 PST::@:[16967]: LOG: aborting startup due to startup process failure
Not sure if anyone can point me in the right direction. I didn't install the server but I'm one of the people who uses it extensively. But I broke it and now I need to fix it...
Nicholas Wilson <nwilson5@gmail.com> writes: > I'm running postgresql 9.0. > I was running several processes and did "sudo service postgres restart" and > it has thrown a fit. > 2012-02-24 12:45:13 PST::@:[16968]: PANIC: GIN metapage disappeared > 2012-02-24 12:45:13 PST::@:[16968]: CONTEXT: xlog redo Update metapage, > node: 1663/16558714/114537692 blkno: 85 Hmm ... had you recently dropped a GIN index? It looks to me like this code is not obeying the proper coding conventions for WAL recovery (in ginxlog.c): metabuffer = XLogReadBuffer(data->node, GIN_METAPAGE_BLKNO, false); if (!BufferIsValid(metabuffer)) elog(PANIC, "GIN metapage disappeared"); metapage = BufferGetPage(metabuffer); A quick-and-dirty patch would be to change the elog call to just a "return;". Meanwhile, you should not have gotten into this situation if the server was allowed to do a clean shutdown ... does your service script do a "mode immediate" stop? If so, maybe that should be reconsidered. regards, tom lane