Thread: [Fwd: "pg_regress: initdb failed" with git tree]
Hi all, I'm new here, but I hope I can help as much as I can/know. The error shown in the subject line is what I get when issuing "make check" in src/test/regress with the latest git tree. OS is Debian testing/unstable with 2.6.33-rc2 kernel from Linus' tree. Anything that I'm missing?
Aioanei Rares wrote: > Hi all, I'm new here, but I hope I can help as much as I can/know. The > error shown in the subject line is what I get when issuing "make > check" in src/test/regress with the latest git tree. OS is Debian > testing/unstable with 2.6.33-rc2 kernel from Linus' tree. > Anything that I'm missing? Can you show the full text of the output leading up to that error? There are lots of reasons why initdb can fail, but without more details I wouldn't even venture a guess which one you're running into. -- Greg Smith 2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.com
Greg Smith wrote: > Aioanei Rares wrote: >> Hi all, I'm new here, but I hope I can help as much as I can/know. >> The error shown in the subject line is what I get when issuing "make >> check" in src/test/regress with the latest git tree. OS is >> Debian testing/unstable with 2.6.33-rc2 kernel from Linus' >> tree. Anything that I'm missing? > > Can you show the full text of the output leading up to that error? > There are lots of reasons why initdb can fail, but without more > details I wouldn't even venture a guess which one you're running into. arares@debian:~/postgresql/src/test/regress$ make check make -C ../../../src/port all make[1]: Entering directory `/home/arares/postgresql/src/port' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/arares/postgresql/src/port' rm -rf ./testtablespace mkdir ./testtablespace ./pg_regress --inputdir=. --dlpath=. --multibyte=SQL_ASCII --temp-install=./tmp_check --top-builddir=../../.. --schedule=./parallel_schedule ============== removing existing temp installation ============== ============== creating temporary installation ============== ============== initializing database system ============== pg_regress: initdb failed Examine /home/arares/postgresql/src/test/regress/log/initdb.log for the reason. Command was: "/home/arares/postgresql/src/test/regress/./tmp_check/install//usr/local/pgsql/bin/initdb" -D "/home/arares/postgresql/src/test/regress/./tmp_check/data" -L "/home/arares/postgresql/src/test/regress/./tmp_check/install//usr/local/pgsql/share" --noclean > "/home/arares/postgresql/src/test/regress/log/initdb.log" 2>&1 make: *** [check] Error 2
Aioanei Rares wrote: > pg_regress: initdb failed > Examine /home/arares/postgresql/src/test/regress/log/initdb.log for > the reason. That's the file that will have an explanation as to what went wrong in it. -- Greg Smith 2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.com
Greg Smith wrote: > Aioanei Rares wrote: >> pg_regress: initdb failed >> Examine /home/arares/postgresql/src/test/regress/log/initdb.log for >> the reason. > > That's the file that will have an explanation as to what went wrong in > it. > Yes, I looked into it, but it doesn't really help me; you will find it attached. Running in noclean mode. Mistakes will not be cleaned up. The files belonging to this database system will be owned by user "arares". This user must also own the server process. The database cluster will be initialized with locales COLLATE: en_US.UTF-8 CTYPE: en_US.UTF-8 MESSAGES: C MONETARY: en_US.UTF-8 NUMERIC: en_US.UTF-8 TIME: en_US.UTF-8 The default database encoding has accordingly been set to UTF8. The default text search configuration will be set to "english". creating directory /home/arares/postgresql/src/test/regress/./tmp_check/data ... ok creating subdirectories ... ok selecting default max_connections ... 100 selecting default shared_buffers ... 24MB creating configuration files ... ok creating template1 database in /home/arares/postgresql/src/test/regress/./tmp_check/data/base/1 ... ok initializing pg_authid ... ok initializing dependencies ... FATAL: compressed data is corrupt child process exited with exit code 1 initdb: data directory "/home/arares/postgresql/src/test/regress/./tmp_check/data" not removed at user's request
Aioanei Rares wrote: >>> pg_regress: initdb failed >>> Examine /home/arares/postgresql/src/test/regress/log/initdb.log for >>> the reason. So here's the problem line: initializing dependencies ... FATAL: compressed data is corrupt That's coming from pretty deep inside PostgreSQL. Large bits of data that get inserted are compressed into what the database calls TOAST relations. This error shows up when the database tries to decompress those TOAST bits back into the original bytes again. That should never fail. Possible causes here: 1) System hardware instability. Intermittent RAM can cause this. I'd run a pass of memtest86+ just to rule that out in this situation, just to keep from chasing after the wrong thing 2) Buggy underlying OS, driver, or system library, somehow corrupting data that's been written before or during when it gets read back again. 3) PostgreSQL bug. Basically the tree is to figure out if it's specific to your system, then if it's specific to everyone one running the same Debian version you are, and then if neither of those are the case it might be possible to trace this down as a PostgreSQL issue. Not sure if you have any alternate systems to test against. The main reason I wouldn't assume it's a PostgreSQL bug initially is just because there are so many entries in the PostgreSQL buildfarm running this same test all the time without any problems. I think you're running a newer OS and libraries than any of them so far though. -- Greg Smith 2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.com
Greg Smith wrote: > Aioanei Rares wrote: >>>> pg_regress: initdb failed >>>> Examine /home/arares/postgresql/src/test/regress/log/initdb.log for >>>> the reason. > > So here's the problem line: > > initializing dependencies ... FATAL: compressed data is corrupt > > > That's coming from pretty deep inside PostgreSQL. Large bits of data > that get inserted are compressed into what the database calls TOAST > relations. This error shows up when the database tries to decompress > those TOAST bits back into the original bytes again. That should > never fail. > > Possible causes here: > > 1) System hardware instability. Intermittent RAM can cause this. I'd > run a pass of memtest86+ just to rule that out in this situation, just > to keep from chasing after the wrong thing > 2) Buggy underlying OS, driver, or system library, somehow corrupting > data that's been written before or during when it gets read back again. > 3) PostgreSQL bug. > > Basically the tree is to figure out if it's specific to your system, > then if it's specific to everyone one running the same Debian version > you are, and then if neither of those are the case it might be > possible to trace this down as a PostgreSQL issue. Not sure if you > have any alternate systems to test against. The main reason I > wouldn't assume it's a PostgreSQL bug initially is just because there > are so many entries in the PostgreSQL buildfarm running this same test > all the time without any problems. I think you're running a newer OS > and libraries than any of them so far though. > It fails on two very different (hardware-wise) machine, both with Debian, and also on a Fedora 12 machine, different from the 1st two.
On Wed, 2009-12-30 at 19:31 +0200, Aioanei Rares wrote: > > > It fails on two very different (hardware-wise) machine, both with > Debian, and also on a Fedora 12 machine, different from the 1st two. FWIW, I could build it on Fedora 7-8-9-11-12 and RHEL 4-5 w/out any issues. -- Devrim GÜNDÜZ, RHCE Command Prompt - http://www.CommandPrompt.com devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
Attachment
Devrim GÜNDÜZ wrote: > On Wed, 2009-12-30 at 19:31 +0200, Aioanei Rares wrote: > >> It fails on two very different (hardware-wise) machine, both with >> Debian, and also on a Fedora 12 machine, different from the 1st two. >> > > FWIW, I could build it on Fedora 7-8-9-11-12 and RHEL 4-5 w/out any > issues. > I deleted the whole postgresql folder and cloned it again and now it works ok. Sorry for the noise.