[Fwd: "pg_regress: initdb failed" with git tree]

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(at)2ndQuadrant(dot)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(at)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(at)2ndQuadrant(dot)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.

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(at)2ndQuadrant(dot)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

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.