Re: pg_upgrade broken by xlog numbering - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_upgrade broken by xlog numbering
Date
Msg-id 23232.1340639425@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_upgrade broken by xlog numbering  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: pg_upgrade broken by xlog numbering  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On MacOS X, on latest sources, initdb fails:

> creating directory /Users/rhaas/pgsql/src/test/regress/./tmp_check/data ... ok
> creating subdirectories ... ok
> selecting default max_connections ... 100
> selecting default shared_buffers ... 32MB
> creating configuration files ... ok
> creating template1 database in
> /Users/rhaas/pgsql/src/test/regress/./tmp_check/data/base/1 ... ok
> initializing pg_authid ... ok
> initializing dependencies ... ok
> creating system views ... ok
> loading system objects' descriptions ... ok
> creating collations ... ok
> creating conversions ... ok
> creating dictionaries ... FATAL:  control file contains invalid data
> child process exited with exit code 1

Same for me.  It's crashing here:
   if (ControlFile->state < DB_SHUTDOWNED ||       ControlFile->state > DB_IN_PRODUCTION ||
!XRecOffIsValid(ControlFile->checkPoint))      ereport(FATAL,               (errmsg("control file contains invalid
data")));

state == DB_SHUTDOWNED, so the problem is with the XRecOffIsValid test.
ControlFile->checkPoint == 19972072 (0x130BFE8), what's wrong with that?

(I suppose the reason this is only failing on some machines is
platform-specific variations in xlog entry size, but it's still a bit
distressing that this got committed in such a broken state.)
        regards, tom lane


pgsql-hackers by date:

Previous
From: Euler Taveira
Date:
Subject: Re: libpq compression
Next
From: Alvaro Herrera
Date:
Subject: Re: warning handling in Perl scripts