Problems with 7.3.1

Started by Olivier PRENANTover 23 years ago8 messageshackers

ohp@pyrenet.fr

over 23 years ago

Hi every one and happy Xmas. Hope you can still answer that one.

Waiting for my brand you server, I've installed an old bi-PII 300 unser
unixware 713 and trying postgresql 7.3.1 with it.

Compile works ok however make check fails wile creating pl/pgsql with :
WARNING: bt_getroot[pg_proc_proname_nsp_index]: fixing root page
ERROR: bt_fixroot: not valid old root page.

What could be causing that (I've tested on uw 711 with no problem)

Many thanks in advance

--
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax)
31190 AUTERIVE +33-6-07-63-80-64 (GSM)
FRANCE Email: ohp@pyrenet.fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)

Tom Lane

tgl@sss.pgh.pa.us

over 23 years ago

In reply to: Olivier PRENANT (#1)

Re: Problems with 7.3.1

Olivier PRENANT <ohp@pyrenet.fr> writes:

Compile works ok however make check fails wile creating pl/pgsql with :
WARNING: bt_getroot[pg_proc_proname_nsp_index]: fixing root page
ERROR: bt_fixroot: not valid old root page.

Wow. Is the behavior reproducible? How about if you go ahead and
install, and do a plain "make installcheck" (or even just try a manual
createlang in a fresh database)?

That code thinks it is dealing with a concurrent index root page split,
but there couldn't be any concurrent operations happening during the
create-plpgsql step of a regression test run. Can you step through
_bt_getroot() (it's in src/backend/access/nbtree/nbtpage.c) and figure
out exactly how it's getting confused?

If the behavior is reproducible I'm inclined to suspect a compiler bug;
it's hard to see how _bt_getroot could get so confused otherwise.

regards, tom lane

Olivier PRENANT

ohp@pyrenet.fr

over 23 years ago

In reply to: Tom Lane (#2)

Re: Problems with 7.3.1

Dear Tom
On Thu, 26 Dec 2002, Tom Lane wrote:

Date: Thu, 26 Dec 2002 13:44:51 -0500
From: Tom Lane <tgl@sss.pgh.pa.us>
To: ohp@pyrenet.fr
Cc: pgsql-hackers list <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Problems with 7.3.1

Olivier PRENANT <ohp@pyrenet.fr> writes:

Compile works ok however make check fails wile creating pl/pgsql with :
WARNING: bt_getroot[pg_proc_proname_nsp_index]: fixing root page
ERROR: bt_fixroot: not valid old root page.

Wow. Is the behavior reproducible? How about if you go ahead and
install, and do a plain "make installcheck" (or even just try a manual
createlang in a fresh database)?

Yes it is! each time, even with make install make installcheck

That code thinks it is dealing with a concurrent index root page split,
but there couldn't be any concurrent operations happening during the
create-plpgsql step of a regression test run. Can you step through
_bt_getroot() (it's in src/backend/access/nbtree/nbtpage.c) and figure
out exactly how it's getting confused?

I will, after diner!

If the behavior is reproducible I'm inclined to suspect a compiler bug;
it's hard to see how _bt_getroot could get so confused otherwise.

AFAIK, the 711b compiler was buggy, but 712 was ok and 713 should at least
be s good as 712 (larry should confirm that!)

In the mean time, I'll try with 7.3 and 7.2.3

regards,

regards, tom lane

Olivier PRENANT

ohp@pyrenet.fr

over 23 years ago

In reply to: Tom Lane (#2)

Re: Problems with 7.3.1

Tom,

I'm puzzled!

I tried postgresql 7.3 and 7.3.1 and they both fail regressin when
creating plpgsql language. However, when installed, createlang plpgsql
template1 work like a charm.

Could it be because the machine is slow (and disks too!)

Regards,
On Thu, 26 Dec 2002, Tom Lane wrote:

Date: Thu, 26 Dec 2002 13:44:51 -0500
From: Tom Lane <tgl@sss.pgh.pa.us>
To: ohp@pyrenet.fr
Cc: pgsql-hackers list <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Problems with 7.3.1

Olivier PRENANT <ohp@pyrenet.fr> writes:

Compile works ok however make check fails wile creating pl/pgsql with :
WARNING: bt_getroot[pg_proc_proname_nsp_index]: fixing root page
ERROR: bt_fixroot: not valid old root page.

Wow. Is the behavior reproducible? How about if you go ahead and
install, and do a plain "make installcheck" (or even just try a manual
createlang in a fresh database)?

That code thinks it is dealing with a concurrent index root page split,
but there couldn't be any concurrent operations happening during the
create-plpgsql step of a regression test run. Can you step through
_bt_getroot() (it's in src/backend/access/nbtree/nbtpage.c) and figure
out exactly how it's getting confused?

If the behavior is reproducible I'm inclined to suspect a compiler bug;
it's hard to see how _bt_getroot could get so confused otherwise.

regards, tom lane

Tom Lane

tgl@sss.pgh.pa.us

over 23 years ago

In reply to: Olivier PRENANT (#4)

Re: Problems with 7.3.1

Olivier PRENANT <ohp@pyrenet.fr> writes:

I tried postgresql 7.3 and 7.3.1 and they both fail regressin when
creating plpgsql language. However, when installed, createlang plpgsql
template1 work like a charm.

Interesting. Would you try another test: now that you've completed the
installation, does "make check" work? I am wondering if "make check"
was picking up the wrong version of plpgsql.so, ie, the one from your
pre-7.3 installation. (I'm not very clear on how a wrong version of
plpgsql.so would result in the particular failure you observed, but this
is the only theory I can think of right now...)

regards, tom lane

Olivier PRENANT

ohp@pyrenet.fr

over 23 years ago

In reply to: Tom Lane (#5)

Re: Problems with 7.3.1

Hi Tom

Here are some news and tests I did and am still doing:

1) there is no previous installation so that can't be a library problem
(good thing!)

2) My tests and compiles are running on data disk ibm 18G uw and fail.

I ended up intalling on the root disk and installcheck did work ok!!

I just finish low reformating the 2 data disk , recreate file systems and
reload. Make check stiil fails at the same point, driver shows no disk
error...

Anymore idea?

Regards,
On Fri, 27 Dec 2002, Tom Lane wrote:

Date: Fri, 27 Dec 2002 11:34:01 -0500
From: Tom Lane <tgl@sss.pgh.pa.us>
To: ohp@pyrenet.fr
Cc: pgsql-hackers list <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Problems with 7.3.1

Olivier PRENANT <ohp@pyrenet.fr> writes:

I tried postgresql 7.3 and 7.3.1 and they both fail regressin when
creating plpgsql language. However, when installed, createlang plpgsql
template1 work like a charm.

Interesting. Would you try another test: now that you've completed the
installation, does "make check" work? I am wondering if "make check"
was picking up the wrong version of plpgsql.so, ie, the one from your
pre-7.3 installation. (I'm not very clear on how a wrong version of
plpgsql.so would result in the particular failure you observed, but this
is the only theory I can think of right now...)

regards, tom lane

Larry Rosenman

ler@lerctr.org

over 23 years ago

In reply to: Olivier PRENANT (#6)

Re: Problems with 7.3.1

--On Friday, December 27, 2002 18:37:24 +0100 Olivier PRENANT
<ohp@pyrenet.fr> wrote:

Hi Tom

Here are some news and tests I did and am still doing:

1) there is no previous installation so that can't be a library problem
(good thing!)

2) My tests and compiles are running on data disk ibm 18G uw and fail.

I ended up intalling on the root disk and installcheck did work ok!!

I just finish low reformating the 2 data disk , recreate file systems and
reload. Make check stiil fails at the same point, driver shows no disk
error...

Anymore idea?

Olivier,
Mine works fine on the Beta (no media yet :-( for the real release).

I can give you an account on my box if you want a reference point.

LER

Regards,
On Fri, 27 Dec 2002, Tom Lane wrote:

Date: Fri, 27 Dec 2002 11:34:01 -0500
From: Tom Lane <tgl@sss.pgh.pa.us>
To: ohp@pyrenet.fr
Cc: pgsql-hackers list <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Problems with 7.3.1

Olivier PRENANT <ohp@pyrenet.fr> writes:

I tried postgresql 7.3 and 7.3.1 and they both fail regressin when
creating plpgsql language. However, when installed, createlang plpgsql
template1 work like a charm.

Interesting. Would you try another test: now that you've completed the
installation, does "make check" work? I am wondering if "make check"
was picking up the wrong version of plpgsql.so, ie, the one from your
pre-7.3 installation. (I'm not very clear on how a wrong version of
plpgsql.so would result in the particular failure you observed, but this
is the only theory I can think of right now...)

regards, tom lane

--
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax)
31190 AUTERIVE +33-6-07-63-80-64 (GSM)
FRANCE Email: ohp@pyrenet.fr
-------------------------------------------------------------------------
----- Make your life a dream, make your dream a reality. (St Exupery)

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

Olivier PRENANT

ohp@pyrenet.fr

over 23 years ago

In reply to: Tom Lane (#5)

Re: Problems with 7.3.1

Tom, I've re-done all tests and I confirm that it works ok on the root
disk but not on the others.

Ok, this is an old machine but, should I send you a tgz of th pgsql
directory if you want to analyse the files? Maybe my strange system
triggers an unknown bug?

Regards,
On Fri, 27 Dec 2002, Tom Lane wrote:

Date: Fri, 27 Dec 2002 11:34:01 -0500
From: Tom Lane <tgl@sss.pgh.pa.us>
To: ohp@pyrenet.fr
Cc: pgsql-hackers list <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Problems with 7.3.1

Olivier PRENANT <ohp@pyrenet.fr> writes:

I tried postgresql 7.3 and 7.3.1 and they both fail regressin when
creating plpgsql language. However, when installed, createlang plpgsql
template1 work like a charm.

Interesting. Would you try another test: now that you've completed the
installation, does "make check" work? I am wondering if "make check"
was picking up the wrong version of plpgsql.so, ie, the one from your
pre-7.3 installation. (I'm not very clear on how a wrong version of
plpgsql.so would result in the particular failure you observed, but this
is the only theory I can think of right now...)

regards, tom lane