Re: Initdb panic: invalid record offset at 0/0 creating - Mailing list pgsql-general

From Agnes Bocchino
Subject Re: Initdb panic: invalid record offset at 0/0 creating
Date
Msg-id 43D5E5DE.5060705@bull.net
Whole thread Raw
In response to Re: Initdb panic: invalid record offset at 0/0 creating template1]  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Initdb panic: invalid record offset at 0/0 creating template1]
List pgsql-general
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



pgsql-general by date:

Previous
From: Greg Stark
Date:
Subject: Re: hardware checks (was Re: invalid memory alloc request size)
Next
From: "R, Rajesh (STSD)"
Date:
Subject: Re: [HACKERS] [PATCH] Better way to check for getaddrinfo function.