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


---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

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.

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

"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


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

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

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend