Обсуждение: Initdb panic: invalid record offset at 0/0 creating template1]
Hello, I work with Agnès Bocchino who have posted a message on the NOVICE mailing-list on an initdb error. Maybe we must post this message in the GENERAL mailing-list. I try, hoping someone knows this error. Regards, Alexandra DANTE -------- Message original -------- Sujet: [NOVICE] Initdb panic: invalid record offset at 0/0 creating template1 Date: Fri, 20 Jan 2006 07:50:32 +0100 De: Agnes Bocchino <agnes.bocchino@bull.net> Pour: pgsql-novice@postgresql.org Hi, we recompiled and built an RPM on IA64, release of postgresql : 8.1.1, on RHEL4 update 2, the installation of the rpm seem to be good, we install with --nodeps , and we indicate the path for the library's /opt/intel_cc_80/lib but when trying to init with the user account "pg_811", it fall in panic, our too ...........we don't know what could be wrong, is there a link with shared memory of our system ? thanks for help _here is the error : _[pg_811@bt3 PGS]$ initdb -D /home/PGS/V811 The files belonging to this database system will be owned by user "pg_811". This user must also own the server process. The database cluster will be initialized with locale en_US.UTF-8. The default database encoding has accordingly been set to UTF8. fixing permissions on existing directory /home/PGS/V811 ... ok creating directory /home/PGS/V811/global ... ok creating directory /home/PGS/V811/pg_xlog ... ok creating directory /home/PGS/V811/pg_xlog/archive_status ... ok creating directory /home/PGS/V811/pg_clog ... ok creating directory /home/PGS/V811/pg_subtrans ... ok creating directory /home/PGS/V811/pg_twophase ... ok creating directory /home/PGS/V811/pg_multixact/members ... ok creating directory /home/PGS/V811/pg_multixact/offsets ... ok creating directory /home/PGS/V811/base ... ok creating directory /home/PGS/V811/base/1 ... ok creating directory /home/PGS/V811/pg_tblspc ... ok selecting default max_connections ... 100 selecting default shared_buffers ... 1000 creating configuration files ... ok creating template1 database in /home/PGS/V811/base/1 ... PANIC: invalid record offset at 0/0 child process was terminated by signal 6 initdb: removing contents of data directory "/home/PGS/V811" _and in mode debug the end of debugs messages are :_ DEBUG: TZ "Etc/GMT+3" scores 0: at 1074121200 2004-01-14 20:00:00 std versus 2004-01-15 00:00:00 std DEBUG: TZ "Etc/UCT" scores 0: at 1074121200 2004-01-14 23:00:00 std versus 2004-01-15 00:00:00 std DEBUG: TZ "Etc/UTC" scores 0: at 1074121200 2004-01-14 23:00:00 std versus 2004-01-15 00:00:00 std DEBUG: TZ "Etc/GMT-12" scores 0: at 1074121200 2004-01-15 11:00:00 std versus 2004-01-15 00:00:00 std DEBUG: TZ "Etc/GMT-4" scores 0: at 1074121200 2004-01-15 03:00:00 std versus 2004-01-15 00:00:00 std DEBUG: invoking IpcMemoryCreate(size=11083776) LOG: database system was shut down at 2006-01-20 07:13:57 CET LOG: invalid primary checkpoint link in control file PANIC: invalid record offset at 0/0 child process was terminated by signal 6 initdb: removing contents of data directory "/home/PGS/V811" [pg_811@bt3 PGS]$ ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
DANTE ALEXANDRA <ALEXANDRA.DANTE@BULL.NET> writes:
> we recompiled and built an RPM on IA64, release of postgresql : 8.1.1,
> on RHEL4 update 2,
> the installation of the rpm seem to be good,
> we install with --nodeps , and we indicate the path for the library's
> /opt/intel_cc_80/lib
> but when trying to init with the user account "pg_811",
> it fall in panic,
Whose RPM did you use, and did you use any special options? Why did
you feel it necessary to use --nodeps?
> DEBUG: invoking IpcMemoryCreate(size=11083776)
> LOG: database system was shut down at 2006-01-20 07:13:57 CET
> LOG: invalid primary checkpoint link in control file
> PANIC: invalid record offset at 0/0
> child process was terminated by signal 6
Hm, I wonder what's getting written into the files ... would you run
initdb with --noclean and then post the results of
* pg_controldata $PGDATA
* od -x $PGDATA/pg_xlog/000000010000000000000000
(I'm assuming that the file is there and od won't produce much output
... if it comes to megabytes don't post it ...)
regards, tom lane
Hello Tom,
We have generated a new rpm as we haven't found a 8.1.0 rpm for IA-64 on
Red Hat Enterprise Linux 4 on the PostGreSQL web site. We have compiled
PostGreSQL v8.1.0 and generated the rpm with the intel compiler "icc".
In the spec file, we have used these options for ./configure :
./configure CC=/opt/intel_cc_80/bin/icc CFLAGS="-no-gcc -O2 -w
-ansi_alias -D__ICC".
When we have tried to install the rpm generated, we have got an error an
the shared library "libimf.so.6" of the intel compiler. Consequently, we
have launched the command : rpm -ivh --nodeps file.rpm
The error was
error: Failed dependencies:
libimf.so.6()(64bit) is needed by postgresql-8.1.1-1.ia64
and has occured because the intel compiler wasn't installed from an rpm
but from a tar.gz file.
Once PostGreSQL installed, we have tried to launch the "initdb" and got
the error :
DEBUG: invoking IpcMemoryCreate(size=11083776)
LOG: database system was shut down at 2006-01-20 07:13:57 CET
LOG: invalid primary checkpoint link in control file
PANIC: invalid record offset at 0/0
child process was terminated by signal 6
initdb: removing contents of data directory "/home/PGS/V811"
In the ".bash_profile" file of the user used to launched initdb, we
have set the following variables :
PGDIR=/opt/pg_811/PGHOME
PGDATA=/home/PGS/V811
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:.
PATH=$PGDIR/bin:$PATH
LD_LIBRARY_PATH=$PGDIR/lib:/opt/intel_cc_80/lib:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH
export PGDIR PGDATA PATH
I have launched the commands you have asked, and you will find below the
results :
*[pg_811@bt3 ~]$ initdb --noclean*
Running in noclean mode. Mistakes will not be cleaned up.
The files belonging to this database system will be owned by user "pg_811".
This user must also own the server process.
The database cluster will be initialized with locale en_US.UTF-8.
The default database encoding has accordingly been set to UTF8.
fixing permissions on existing directory /home/PGS/V811 ... ok
creating directory /home/PGS/V811/global ... ok
creating directory /home/PGS/V811/pg_xlog ... ok
creating directory /home/PGS/V811/pg_xlog/archive_status ... ok
creating directory /home/PGS/V811/pg_clog ... ok
creating directory /home/PGS/V811/pg_subtrans ... ok
creating directory /home/PGS/V811/pg_twophase ... ok
creating directory /home/PGS/V811/pg_multixact/members ... ok
creating directory /home/PGS/V811/pg_multixact/offsets ... ok
creating directory /home/PGS/V811/base ... ok
creating directory /home/PGS/V811/base/1 ... ok
creating directory /home/PGS/V811/pg_tblspc ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 1000
creating configuration files ... ok
creating template1 database in /home/PGS/V811/base/1 ... PANIC: invalid
record offset at 0/0
child process was terminated by signal 6
initdb: data directory "/home/PGS/V811" not removed at user's request
[pg_811@bt3 ~]$
---------------------------------------------------------------------------------------------------
*[pg_811@bt3 V811]$ pg_controldata $PGDATA*
pg_control version number: 812
Catalog version number: 200510211
Database system identifier: 4886687050337353727
Database cluster state: shut down
pg_control last modified: Fri 20 Jan 2006 04:21:31 PM CET
Current log file ID: 0
Next log file segment: 1
Latest checkpoint location: 0/20
Prior checkpoint location: 0/0
Latest checkpoint's REDO location: 0/20
Latest checkpoint's UNDO location: 0/20
Latest checkpoint's TimeLineID: 1
Latest checkpoint's NextXID: 3
Latest checkpoint's NextOID: 10000
Latest checkpoint's NextMultiXactId: 1
Latest checkpoint's NextMultiOffset: 0
Time of latest checkpoint: Fri 20 Jan 2006 04:21:31 PM CET
Maximum data alignment: 8
Database block size: 8192
Blocks per segment of large relation: 131072
Bytes per WAL segment: 16777216
Maximum length of identifiers: 64
Maximum columns in an index: 32
Date/time type storage: floating-point numbers
Maximum length of locale name: 128
LC_COLLATE: en_US.UTF-8
LC_CTYPE: en_US.UTF-8
[pg_811@bt3 V811]$
---------------------------------------------------------------------------------------------------
*[pg_811@bt3 V811]$ od -x $PGDATA/pg_xlog/000000010000000000000000*
0000000 d05d 0002 0001 0000 0000 0000 0000 0000
0000020 ffff 43db fffb 43d0 0000 0100 0000 0000
0000040 68f5 5b77 0000 0000 0000 0000 0000 0000
0000060 0050 0000 0030 0000 0000 0000 0000 0000
0000100 0000 0000 0020 0000 0000 0000 0020 0000
0000120 0001 0000 0003 0000 2710 0000 0001 0000
0000140 0000 0000 0000 0000 fffb 43d0 0000 0000
0000160 0000 0000 0000 0000 0000 0000 0000 0000
*
100000000
The result file is about 16MB... I don't post it, but I can do an
archive of this file if you want...
I hope you would explain us with initdb fails.
Thank you for your help.
Regards,
Alexandra DANTE
Tom Lane a écrit :
>DANTE ALEXANDRA <ALEXANDRA.DANTE@BULL.NET> writes:
>
>
>>we recompiled and built an RPM on IA64, release of postgresql : 8.1.1,
>>on RHEL4 update 2,
>>the installation of the rpm seem to be good,
>>we install with --nodeps , and we indicate the path for the library's
>>/opt/intel_cc_80/lib
>>but when trying to init with the user account "pg_811",
>>it fall in panic,
>>
>>
>
>Whose RPM did you use, and did you use any special options? Why did
>you feel it necessary to use --nodeps?
>
>
>
>>DEBUG: invoking IpcMemoryCreate(size=11083776)
>>LOG: database system was shut down at 2006-01-20 07:13:57 CET
>>LOG: invalid primary checkpoint link in control file
>>PANIC: invalid record offset at 0/0
>>child process was terminated by signal 6
>>
>>
>
>Hm, I wonder what's getting written into the files ... would you run
>initdb with --noclean and then post the results of
> * pg_controldata $PGDATA
> * od -x $PGDATA/pg_xlog/000000010000000000000000
>(I'm assuming that the file is there and od won't produce much output
>... if it comes to megabytes don't post it ...)
>
> regards, tom lane
>
>
>
DANTE ALEXANDRA <ALEXANDRA.DANTE@BULL.NET> writes:
> We have generated a new rpm as we haven't found a 8.1.0 rpm for IA-64 on
> Red Hat Enterprise Linux 4 on the PostGreSQL web site. We have compiled
> PostGreSQL v8.1.0 and generated the rpm with the intel compiler "icc".
> In the spec file, we have used these options for ./configure :
> ./configure CC=/opt/intel_cc_80/bin/icc CFLAGS="-no-gcc -O2 -w
> -ansi_alias -D__ICC".
Do you know that this compiler generates trustworthy code with those
options? The contents of the pg_control file are clearly good according
to the dump from pg_controldata, and yet we have
> LOG: invalid primary checkpoint link in control file
> PANIC: invalid record offset at 0/0
The easiest explanation I can see for this is that the compiler has
gotten the XRecOffIsValid test at the top of ReadCheckpointRecord
(in src/backend/access/transam/xlog.c, line 4854 as of 8.1.2) backwards.
The first time through, with the perfectly valid primary checkpoint
location (0/20) it mistakenly decides the value is not valid and prints
the LOG message. This leads to a second call with the invalid prior
checkpoint location (0/0), when it mistakenly falls through and calls
ReadRecord, which properly PANICs. Given that ReadRecord is using the
exact same macro to decide the offset is invalid (line 2668), it's hard
to conclude anything except a compiler bug.
regards, tom lane
Hello Tom >Do you know that this compiler generates trustworthy code with those >options? The contents of the pg_control file are clearly good according >to the dump from pg_controldata, and yet we have > > > Perhaps we should use others options, could you tell us which are the write options with icc (options without problems running Postgresql), As you tell us about icc compiler bug, I take the latest release of Intel compiler (9.0), as there was an error, I have to add in the spec file the LD_LIBRARY_PATH for intel library "error while loading shared libraries: libimf.so.6: cannot open shared object file:" Next there no more error during the compilation, one error when trying to compress file when packaging the RPM : /usr/lib/rpm/redhat/brp-compress + /usr/lib/rpm/redhat/brp-strip /usr/bin/strip + /usr/lib/rpm/redhat/brp-strip-static-archive /usr/bin/strip /usr/bin/strip: there are no sections to be copied! /usr/lib/rpm/redhat/brp-strip-static-archive: line 11: 26613 Segmentation fault $STRIP -g $f so I had in the spec file : %define __spec_install_post : and now, we initialising lauching initdb, we have no more the error in creating the template database but another one error occurs: so I have execute the initdb as you tell us in previous mail : Do you have some explanation or/and tips on how to build a successfull rpm on ia64, with icc, perhaps we shoud not ........please tell us Thanks Tom hereafter the last run and error messages : [pg_811@bt3 PGS]$ creating directory /home/PGS/V811/pg_subtrans ... ok creating directory /home/PGS/V811/pg_twophase ... ok creating directory /home/PGS/V811/pg_multixact/members ... ok creating directory /home/PGS/V811/pg_multixact/offsets ... ok creating directory /home/PGS/V811/base ... ok creating directory /home/PGS/V811/base/1 ... ok creating directory /home/PGS/V811/pg_tblspc ... ok selecting default max_connections ... 100 selecting default shared_buffers ... 1000 creating configuration files ... ok creating template1 database in /home/PGS/V811/base/1 ... ok initializing pg_authid ... PANIC: invalid redo/undo record in shutdown checkpoint sh: line 1: 24229 Aborted "/opt/pg_811/PGHOME/bin/postgres" -F -O -c search_path=pg_catalog -c exit_on_error=true temp late1 >/dev/null child process exited with exit code 134 initdb: data directory "/home/PGS/V811" not removed at user's request [pg_811@bt3 i-s]$ pg_controldata $PGDATA* pg_control version number: 812 Catalog version number: 200510211 Database system identifier: 4887835219649830077 Database cluster state: shut down pg_control last modified: Mon 23 Jan 2006 06:37:01 PM CET Current log file ID: 0 Next log file segment: 1 Latest checkpoint location: 0/98 Prior checkpoint location: 0/20 Latest checkpoint's REDO location: 0/98 Latest checkpoint's UNDO location: 0/0 Latest checkpoint's TimeLineID: 1 Latest checkpoint's NextXID: 3 Latest checkpoint's NextOID: 10284 Latest checkpoint's NextMultiXactId: 1 Latest checkpoint's NextMultiOffset: 0 Time of latest checkpoint: Mon 23 Jan 2006 06:37:01 PM CET Maximum data alignment: 8 Database block size: 8192 Blocks per segment of large relation: 131072 Bytes per WAL segment: 16777216 Maximum length of identifiers: 64 Maximum columns in an index: 32 Date/time type storage: floating-point numbers Maximum length of locale name: 128 LC_COLLATE: en_US.UTF-8 LC_CTYPE: en_US.UTF-8 [pg_811@bt3 i-s]$ [pg_811@bt3 i-s]$ [pg_811@bt3 i-s]$ od -x $PGDATA/pg_xlog/000000010000000000000000* 0000000 d05d 0002 0001 0000 0000 0000 0000 0000 0000020 1cbd 43df 143c 43d5 0000 0100 0000 0000 0000040 f3bd 3cfc 0000 0000 0000 0000 0000 0000 0000060 0050 0000 0030 0000 0000 0000 0000 0000 0000100 0000 0000 0020 0000 0000 0000 0020 0000 0000120 0001 0000 0003 0000 2710 0000 0001 0000 0000140 0000 0000 0000 0000 143c 43d5 0000 0000 0000160 96e3 44be 0000 0000 0020 0000 0001 0000 0000200 0024 0000 0004 0000 0030 0000 0000 0000 0000220 4710 0000 0000 0000 9a94 b046 0000 0000 0000240 0070 0000 0000 0000 0050 0000 0030 0000 0000260 0000 0000 0000 0000 0000 0000 0098 0000 0000300 0000 0000 0000 0000 0001 0000 0003 0000 0000320 282c 0000 0001 0000 0000 0000 0000 0000 0000340 143d 43d5 0000 0000 0000 0000 0000 0000 0000360 0000 0000 0000 0000 0000 0000 0000 0000 * 100000000
Agnes Bocchino <agnes.bocchino@bull.net> writes:
> Do you have some explanation or/and tips on how to build a successfull
> rpm on ia64, with icc,
> perhaps we shoud not ........please tell us
Perhaps you should use gcc?
I don't personally have the time or interest to dig into this.
Considering that PG works fine on several other 64-bit platforms,
it seems unlikely (though not impossible of course) that this is our
bug.
What could be happening is that the RPM packaging involves tools that
aren't compatible with icc. I think you already found that out with
regard to brp-strip, and there may be some more-subtle problems too.
You might try forgetting about RPM entirely and just building from
the source tarball with "configure CC=icc" plus whatever other options
you want.
regards, tom lane
Tom, finally I tried with only this option CC=icc, as there is an another error (error: Could not open %files file /home/postdev/BUILD/postgresql-8.1.1/debugfiles.list), I dont know where this debugfiles.list coming from. I prefered to stop for now , I'll will try later, so I have used gcc and it is fine ! (compiling, installing, initdb,....) regards Agnès Tom Lane wrote: >Agnes Bocchino <agnes.bocchino@bull.net> writes: > > >>Do you have some explanation or/and tips on how to build a successfull >>rpm on ia64, with icc, >>perhaps we shoud not ........please tell us >> >> > >Perhaps you should use gcc? > >I don't personally have the time or interest to dig into this. >Considering that PG works fine on several other 64-bit platforms, >it seems unlikely (though not impossible of course) that this is our >bug. > >What could be happening is that the RPM packaging involves tools that >aren't compatible with icc. I think you already found that out with >regard to brp-strip, and there may be some more-subtle problems too. >You might try forgetting about RPM entirely and just building from >the source tarball with "configure CC=icc" plus whatever other options >you want. > > regards, tom lane > >---------------------------(end of broadcast)--------------------------- >TIP 2: Don't 'kill -9' the postmaster > > >