Обсуждение: postgres will not start up - corrupted on restart

Поиск
Список
Период
Сортировка

postgres will not start up - corrupted on restart

От
Nicholas Wilson
Дата:
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...

Re: postgres will not start up - corrupted on restart

От
Tom Lane
Дата:
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