Re: [HACKERS] Invalid magic number in log file?
Alvaro Herrera [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] 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? [EMAIL PROTECTED]:~$ /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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Invalid magic number in log file?
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? [EMAIL PROTECTED]:~$ /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 Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Invalid magic number in log file?
Alvaro Herrera [EMAIL PROTECTED] 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? [EMAIL PROTECTED]:~$ /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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Invalid magic number in log file?
Gregory Stark wrote: Alvaro Herrera [EMAIL PROTECTED] 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? [EMAIL PROTECTED]:~$ /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 Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
