invalid magic number in log segment

Поиск
Список
Период
Сортировка
От Erikjan Rijkers
Тема invalid magic number in log segment
Дата
Msg-id c3f4f12a1e838f5eb738891415ae3607.squirrel@webmail.xs4all.nl
обсуждение исходный текст
Ответы Re: invalid magic number in log segment  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Список pgsql-hackers
I don't know whether the below constitutes a bug, but:

Daily (sometimes even more often) I recompile 9.4devel (after git pull)  to run a large dev database (100 GB or so).

To avoid frequent initdb and many-hour-restore of data, I do this only when the following two #defines are unchanged:
CATALOG_VERSION_NOin src/include/catalog/catversion.h, and PG_CONTROL_VERSION in src/include/catalog/pg_control.h
 

the goal being to always run the latest db, without having to reload the ~100 GB dev db unexpectedly at inconvenient
times.

Generally, this works OK.

However, the last few weeks I sometimes get, after such recompiling,  'invalid magic number' errors from which I don't
know
how to recover (it means, apparently, an initdb is needed and I have then to reload the database).


2013-12-11 00:15:25.627 CET 25304 LOG:  received smart shutdown request
2013-12-11 00:15:25.631 CET 25306 LOG:  shutting down
2013-12-11 00:15:25.904 CET 25306 LOG:  database system is shut down
2013-12-11 08:11:59.858 CET 25490 LOG:  database system was shut down at 2013-12-11 00:15:25 CET
2013-12-11 08:11:59.901 CET 25490 LOG:  invalid magic number D078 in log segment 000000010000006300000034, offset 0
2013-12-11 08:11:59.901 CET 25490 LOG:  invalid primary checkpoint record
2013-12-11 08:11:59.901 CET 25490 LOG:  invalid magic number D078 in log segment 000000010000006300000034, offset 0
2013-12-11 08:11:59.901 CET 25490 LOG:  invalid secondary checkpoint record
2013-12-11 08:11:59.901 CET 25490 PANIC:  could not locate a valid checkpoint record
2013-12-11 08:12:00.326 CET 25492 FATAL:  the database system is starting up
2013-12-11 08:12:01.328 CET 25493 FATAL:  the database system is starting up
2013-12-11 08:12:01.682 CET 25489 LOG:  startup process (PID 25490) was terminated by signal 6: Aborted
2013-12-11 08:12:01.682 CET 25489 LOG:  aborting startup due to startup process failure


My question is two-fold:

1. (general:)  is this 'invalid magic number' unexpected, and should it be reported always?

2. (for my setup specifically:)  is there any way that I can recognize, beforehand, at the code base level, such an
impending 'invalid magic number' state?
Can de db be recovered from easily? (although this dev database is expendable, it takes many hours to rebuild; I'd like
to
avoid that if possible).

thanks,

Erikjan Rijkers










В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: ANALYZE sampling is too good
Следующее
От: Hannu Krosing
Дата:
Сообщение: Re: ANALYZE sampling is too good