Thread: Invalid magic number in log file?
When starting up a postmaster from an older build on a database initialized with a newer build I'm getting the following errors. I think I saw the same thing earlier going in the opposite direction too. Shouldn't there be some earlier errors firing from the control file version number? stark@oxford:~$ /usr/local/pgsql/bin/postgres -D /var/tmp/db LOG: database system was shut down at 2007-05-14 19:47:51 BST LOG: invalid magic number D061 in log file 0, segment 0, offset 0 LOG: invalid primary checkpoint record LOG: invalid magic number D061 in log file 0, segment 0, offset 0 LOG: invalid secondary checkpoint record PANIC: could not locate a valid checkpoint record LOG: startup process (PID 9590) was terminated by signal 6: Aborted LOG: aborting startup due to startup process failure -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
Gregory Stark wrote: > > When starting up a postmaster from an older build on a database initialized > with a newer build I'm getting the following errors. I think I saw the same > thing earlier going in the opposite direction too. Shouldn't there be some > earlier errors firing from the control file version number? > > stark@oxford:~$ /usr/local/pgsql/bin/postgres -D /var/tmp/db > LOG: database system was shut down at 2007-05-14 19:47:51 BST > LOG: invalid magic number D061 in log file 0, segment 0, offset 0 > LOG: invalid primary checkpoint record > LOG: invalid magic number D061 in log file 0, segment 0, offset 0 > LOG: invalid secondary checkpoint record > PANIC: could not locate a valid checkpoint record > LOG: startup process (PID 9590) was terminated by signal 6: Aborted > LOG: aborting startup due to startup process failure Huh, works for me, what versions were those? -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
"Alvaro Herrera" <alvherre@commandprompt.com> writes: > Gregory Stark wrote: >> >> When starting up a postmaster from an older build on a database initialized >> with a newer build I'm getting the following errors. I think I saw the same >> thing earlier going in the opposite direction too. Shouldn't there be some >> earlier errors firing from the control file version number? >> >> stark@oxford:~$ /usr/local/pgsql/bin/postgres -D /var/tmp/db >> LOG: database system was shut down at 2007-05-14 19:47:51 BST >> LOG: invalid magic number D061 in log file 0, segment 0, offset 0 >> LOG: invalid primary checkpoint record >> LOG: invalid magic number D061 in log file 0, segment 0, offset 0 >> LOG: invalid secondary checkpoint record >> PANIC: could not locate a valid checkpoint record >> LOG: startup process (PID 9590) was terminated by signal 6: Aborted >> LOG: aborting startup due to startup process failure > > Huh, works for me, what versions were those? Well it's cvs HEAD and a checkout from May 1st. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
Gregory Stark wrote: > > "Alvaro Herrera" <alvherre@commandprompt.com> writes: > > > Gregory Stark wrote: > >> > >> When starting up a postmaster from an older build on a database initialized > >> with a newer build I'm getting the following errors. I think I saw the same > >> thing earlier going in the opposite direction too. Shouldn't there be some > >> earlier errors firing from the control file version number? > >> > >> stark@oxford:~$ /usr/local/pgsql/bin/postgres -D /var/tmp/db > >> LOG: database system was shut down at 2007-05-14 19:47:51 BST > >> LOG: invalid magic number D061 in log file 0, segment 0, offset 0 > >> LOG: invalid primary checkpoint record > >> LOG: invalid magic number D061 in log file 0, segment 0, offset 0 > >> LOG: invalid secondary checkpoint record > >> PANIC: could not locate a valid checkpoint record > >> LOG: startup process (PID 9590) was terminated by signal 6: Aborted > >> LOG: aborting startup due to startup process failure > > > > Huh, works for me, what versions were those? > > Well it's cvs HEAD and a checkout from May 1st. It was changed in 1.20 of xlog_internal.h. That particular changeset didn't include a catversion bump nor pg_control magic version change. I think the rationale here is that it was only a change in WAL format, so it shouldn't affect either -- it did change the WAL magic. Maybe the thing to do here is to disallow running a postmaster when the data dir is using a different WAL magic (forcing you to pg_resetxlog or initdb). Does it work if you do a pg_resetxlog and restart? 2007-04-30 17:01 tgl * src/: backend/access/transam/twophase.c (1.30), backend/access/transam/xact.c (1.242), backend/access/transam/xlog.c(1.268), backend/utils/adt/timestamp.c (1.176), include/access/xact.h (1.87), include/access/xlog_internal.h(1.20), include/utils/timestamp.h (1.69): Change the timestamps recorded in transaction commit/abort xlog records from time_t to TimestampTz representation. This provides full gettimeofday() resolution of the timestamps, which might be useful when attempting to do point-in-time recovery --- previously it was not possible to specify the stop point with sub-second resolution. But mostly this is to get rid of TimestampTz-to-time_t conversion overhead during commit. Per my proposal of a day or two back. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Maybe the thing to do here is to disallow running a postmaster when the
> data dir is using a different WAL magic (forcing you to pg_resetxlog or
> initdb).
Which, curiously enough, is exactly what it does ...
I'm not particularly concerned with the user-friendliness of the error
message, since this case would never arise for normal users (the
PG_VERSION check would fire first in any cross-version compatibility
situation). It only matters for hackers tracking CVS HEAD.
regards, tom lane