I did a cvsup and a fresh recompile this morning. But I still get 

ERROR:  fmgr_info: function 683: cache lookup failed

from initdb. Guess I have to dig into it more deeply.

Is anyone else running postgresql with glibc2.0.7 on Linux?

Michael
-- 
Michael Meskes			meskes@online-club.de, meskes@debian.org
Go SF49ers! Go Rhein Fire!	Use Debian GNU/Linux! 

Thu, 20 Aug 1998 07:58:07 +0200
Michael Meskes <meskes@online-club.de>
initdb problem
> I did a cvsup and a fresh recompile this morning. But I still get 
> 
> ERROR:  fmgr_info: function 683: cache lookup failed
> 
> from initdb. Guess I have to dig into it more deeply.
> 
> Is anyone else running postgresql with glibc2.0.7 on Linux?
> 

Just a quick question.  Are people doing a make clean when updating via
cvs.  My patch changed lots of system tables.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Thu, 20 Aug 1998 19:06:43 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] initdb problem
On Thu, Aug 20, 1998 at 07:06:43PM -0400, Bruce Momjian wrote:
> Just a quick question.  Are people doing a make clean when updating via
> cvs.  My patch changed lots of system tables.

Yes, I do.

Michael
-- 
Michael Meskes			meskes@online-club.de, meskes@debian.org
Go SF49ers! Go Rhein Fire!	Use Debian GNU/Linux! 

Sat, 22 Aug 1998 18:09:34 +0200
Michael Meskes <meskes@online-club.de>
Re: [HACKERS] initdb problem

On 22-Aug-98 Michael Meskes wrote:
> On Thu, Aug 20, 1998 at 07:06:43PM -0400, Bruce Momjian wrote:
>> Just a quick question.  Are people doing a make clean when updating via
>> cvs.  My patch changed lots of system tables.
> 
> Yes, I do.

<aolmode>
Me Too!
</aolmode>

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH   email: vev@michvhf.com   flame-mail: /dev/null
       # include <std/disclaimers.h>                   TEAM-OS2
   Online Searchable Campground Listings    http://www.camping-usa.com
       "There is no outfit less entitled to lecture me about bloat
               than the federal government"  -- Tony Snow
==========================================================================



Sun, 23 Aug 1998 09:13:51 -0400 (EDT)
Vince Vielhaber <vev@michvhf.com>
Re: [HACKERS] initdb problem
> On Thu, Aug 20, 1998 at 07:06:43PM -0400, Bruce Momjian wrote:
> > Just a quick question.  Are people doing a make clean when updating via
> > cvs.  My patch changed lots of system tables.
> 
> Yes, I do.

OK, it appears people are still having initdb problems after my patch. 
I have received several reports of problems.  Someone reported a
regression test problem with contraints.sql.  I could reproduce it here,
and fixed it.

The other problems with initdb itself are more difficult.  People seem
to have a variety of initdb failures, and I am at a loss to find a
cause.

I realize this is a major problem, and I want to fix it as soon as I
can.  I am running BSDI under Intel, and everything works fine, so I am
really confused.

First, people have to do a 'make clean', 'make', and 'initdb' after my
patch, but people are already doing that.

Keith Parks <emkxp01@mtcc.demon.co.uk> reported problems right away, and
I tried to recommend solutions.  His most recent change was to blow away
his entire cvs tree and re-download it, on the assumption that it was
not matching the main cvs tree somehow.  Keith, did that fix the
problem?

I have just done the same, to make sure I am in sync, and everything
still works as it should.

What platform are people using.  What failures?  Are they consistent? 
Can someone give me telnet access to a machine that does not work?

Marc, does postgresql.org machine do initdb properly?

Please report problems to me directly, and I will keep trying to find
the cause.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Sun, 23 Aug 1998 14:17:45 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] initdb problem
On Sun, 23 Aug 1998, Bruce Momjian wrote:

> Date: Sun, 23 Aug 1998 14:17:45 -0400 (EDT)
> From: Bruce Momjian <maillist@candle.pha.pa.us>
> To: Michael Meskes <meskes@online-club.de>
> Cc: pgsql-hackers@postgreSQL.org
> Subject: Re: [HACKERS] initdb problem
> 
> > On Thu, Aug 20, 1998 at 07:06:43PM -0400, Bruce Momjian wrote:
> > > Just a quick question.  Are people doing a make clean when updating via
> > > cvs.  My patch changed lots of system tables.
> > 
> > Yes, I do.
> 
> OK, it appears people are still having initdb problems after my patch. 
> I have received several reports of problems.  Someone reported a
> regression test problem with contraints.sql.  I could reproduce it here,
> and fixed it.
> 
> The other problems with initdb itself are more difficult.  People seem
> to have a variety of initdb failures, and I am at a loss to find a
> cause.
> 
> I realize this is a major problem, and I want to fix it as soon as I
> can.  I am running BSDI under Intel, and everything works fine, so I am
> really confused.
> 
> First, people have to do a 'make clean', 'make', and 'initdb' after my
> patch, but people are already doing that.
> 

Yes, I did this.

> Keith Parks <emkxp01@mtcc.demon.co.uk> reported problems right away, and
> I tried to recommend solutions.  His most recent change was to blow away
> his entire cvs tree and re-download it, on the assumption that it was
> not matching the main cvs tree somehow.  Keith, did that fix the
> problem?
> 

Hmm, probably I'll also try re-download cvs.

> I have just done the same, to make sure I am in sync, and everything
> still works as it should.
> 
> What platform are people using.  What failures?  Are they consistent? 
> Can someone give me telnet access to a machine that does not work?
> 

Linux 2.1.117, libc-5.4.46, egcs-2.91.50. My development computer is
in home and I can't give you telnet account :-) 
BTW, what's the best way to have several version of postgres on the
same computer ? 

> Marc, does postgresql.org machine do initdb properly?
> 
> Please report problems to me directly, and I will keep trying to find
> the cause.
> 
> -- 
> Bruce Momjian                          |  830 Blythe Avenue
> maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
>   +  If your life is a hard drive,     |  (610) 353-9879(w)
>   +  Christ can be your backup.        |  (610) 853-3000(h)
> 

_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83


Sun, 23 Aug 1998 23:52:03 +0400 (MSK DST)
Oleg Bartunov <oleg@sai.msu.su>
Re: [HACKERS] initdb problem
> What platform are people using.  What failures?  Are they consistent? 
> Can someone give me telnet access to a machine that does not work?

I would also be interested in hearing the platforms that DO work.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Sun, 23 Aug 1998 17:46:04 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] initdb problem
Bruce,

Just re-downladed cvs and compiled on Linux x86 2.0.35, gcc 2.7.2.3
initd seems runs ok now, regression test fails on:

oidint2 .. failed
oidint4 .. failed
oidname .. failed
.........
geometry .. failed
........
constraints .. failed
........
create_index .. failed
sanity_check .. failed
.........
select .. failed
select_into .. failed
select_distinct .. failed
select_distinct_on .. failed
.........
aggregates .. failed
.........
random .. failed
portals .. failed
misc .. failed
.........
btree_index .. failed
.........
select_views .. failed
alter_table .. failed
portals_p2 .. failed
run_ruletest.sql .. ./regress.sh: sql/run_ruletest.sql.sql: No such file or directory
diff: expected/run_ruletest.sql.out: No such file or directory
diff: results/run_ruletest.sql.out: No such file or directory
ok
setup_ruletest.sql .. ./regress.sh: sql/setup_ruletest.sql.sql: No such file or directory
diff: expected/setup_ruletest.sql.out: No such file or directory
diff: results/setup_ruletest.sql.out: No such file or directory
ok
ACTUAL RESULTS OF REGRESSION TEST ARE NOW IN FILE regress.out
rm regress.o

	Oleg
On Sun, 23 Aug 1998, Bruce Momjian wrote:

> Date: Sun, 23 Aug 1998 17:46:04 -0400 (EDT)
> From: Bruce Momjian <maillist@candle.pha.pa.us>
> To: Bruce Momjian <maillist@candle.pha.pa.us>
> Cc: meskes@online-club.de, pgsql-hackers@postgreSQL.org
> Subject: Re: [HACKERS] initdb problem
> 
> > What platform are people using.  What failures?  Are they consistent? 
> > Can someone give me telnet access to a machine that does not work?
> 
> I would also be interested in hearing the platforms that DO work.
> 
> -- 
> Bruce Momjian                          |  830 Blythe Avenue
> maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
>   +  If your life is a hard drive,     |  (610) 353-9879(w)
>   +  Christ can be your backup.        |  (610) 853-3000(h)
> 

_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83


Mon, 24 Aug 1998 02:26:46 +0400 (MSK DST)
Oleg Bartunov <oleg@sai.msu.su>
Re: [HACKERS] initdb problem
> Bruce,
> 
> Just re-downladed cvs and compiled on Linux x86 2.0.35, gcc 2.7.2.3
> initd seems runs ok now, regression test fails on:

This is GREAT news.  I was feeling guilt about breaking the source tree.

Perhaps CVS has some problem with the size of the change I made.  Not
sure.

If someone else who is having trouble tries re-downloading the whole
tree, and it works, we can recommend this as the solution.
 

> 
> oidint2 .. failed
> oidint4 .. failed
> oidname .. failed

You get these because I removed these types in the patch.  I have asked
Thomas to fix this.

> .........
> geometry .. failed
> ........
> constraints .. failed
> ........
> create_index .. failed
> sanity_check .. failed
> .........
> select .. failed
> select_into .. failed
> select_distinct .. failed
> select_distinct_on .. failed
> .........
> aggregates .. failed
> .........
> random .. failed
> portals .. failed
> misc .. failed
> .........
> btree_index .. failed
> .........
> select_views .. failed
> alter_table .. failed
> portals_p2 .. failed
> run_ruletest.sql .. ./regress.sh: sql/run_ruletest.sql.sql: No such file or directory
> diff: expected/run_ruletest.sql.out: No such file or directory
> diff: results/run_ruletest.sql.out: No such file or directory
> ok
> setup_ruletest.sql .. ./regress.sh: sql/setup_ruletest.sql.sql: No such file or directory
> diff: expected/setup_ruletest.sql.out: No such file or directory
> diff: results/setup_ruletest.sql.out: No such file or directory
> ok
> ACTUAL RESULTS OF REGRESSION TEST ARE NOW IN FILE regress.out

I get the same problems.  regress/checkresults shows the differences are
minor and expected.  The last stuff is because some stuff was renamed,
and I assume Thomas will have it working soon.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Sun, 23 Aug 1998 20:24:58 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] initdb problem
On Sun, Aug 23, 1998 at 11:52:03PM +0400, Oleg Bartunov wrote:
> > What platform are people using.  What failures?  Are they consistent? 
> > Can someone give me telnet access to a machine that does not work?
> > 
> 
> Linux 2.1.117, libc-5.4.46, egcs-2.91.50. My development computer is
> in home and I can't give you telnet account :-) 

I still have the same problem: 

ERROR:  fmgr_info: function 683: cache lookup failed

ERROR:  fmgr_info: function 683: cache lookup failed
 
I'm using Linux-2.1.117, glibc 2.0.7, gcc-2.7.2.3.

And once again now telnet account as we're talking about my private notebook
only connected to the internet occassionally vie modem.

> BTW, what's the best way to have several version of postgres on the
> same computer ? 

I'm interested in this too. I have the Debian prepackaged versoin of 6.3.2
and the development version. Seems to work fine, but then I only run one of
them. To start the other I stop the one running.

Michael
-- 
Michael Meskes			meskes@online-club.de, meskes@debian.org
Go SF49ers! Go Rhein Fire!	Use Debian GNU/Linux! 

Mon, 24 Aug 1998 07:52:27 +0200
Michael Meskes <meskes@online-club.de>
Re: [HACKERS] initdb problem
>OK, it appears people are still having initdb problems after my patch. 
>I have received several reports of problems.  Someone reported a
>regression test problem with contraints.sql.  I could reproduce it here,
>and fixed it.

The constraints test is working now on my FreeBSD box. Thanks.

Another problem I'm having is vacuum seems not working. Is this a
known problem?

regression=> vacuum;
pqReadData() -- backend closed the channel unexpectedly.
	This probably means the backend terminated abnormally before or while processing the request.
We have lost the connection to the backend, so further processing is impossible.  Terminating.

Another things I'm troubled with are that some regression tests make
the backend dump core on my LinuxPPC box.

$ grep -i pqread results/*

results/btree_index.out:pqReadData() -- backend closed the channel unexpectedly.
results/constraints.out:pqReadData() -- backend closed the channel unexpectedly.
results/create_function_1.out:pqReadData() -- backend closed the channel unexpectedly.
results/create_function_2.out:pqReadData() -- backend closed the channel unexpectedly.
results/sanity_check.out:pqReadData() -- backend closed the channel unexpectedly.
results/select_views.out:pqReadData() -- backend closed the channel unexpectedly.
results/triggers.out:pqReadData() -- backend closed the channel unexpectedly.

These were ok on FreeBSD except the sanity_check test(vacuum dumped
core). I will look into these.
--
Tatsuo Ishii
t-ishii@sra.co.jp

Mon, 24 Aug 1998 15:42:25 +0900
t-ishii@sra.co.jp
Re: [HACKERS] initdb problem 
On Mon, Aug 24, 1998 at 02:26:46AM +0400, Oleg Bartunov wrote:
> Just re-downladed cvs and compiled on Linux x86 2.0.35, gcc 2.7.2.3
> initd seems runs ok now, regression test fails on:

I still cannot initdb. Since I have the same kernel and gcc, what library do
you use? I hve glibc 2.0.7.

Michael

-- 
Michael Meskes			meskes@online-club.de, meskes@debian.org
Go SF49ers! Go Rhein Fire!	Use Debian GNU/Linux! 

Mon, 24 Aug 1998 10:28:15 +0200
Michael Meskes <meskes@online-club.de>
Re: [HACKERS] initdb problem
> >OK, it appears people are still having initdb problems after my patch. 
> >I have received several reports of problems.  Someone reported a
> >regression test problem with contraints.sql.  I could reproduce it here,
> >and fixed it.
> 
> The constraints test is working now on my FreeBSD box. Thanks.
> 
> Another problem I'm having is vacuum seems not working. Is this a
> known problem?
> 
> regression=> vacuum;
> pqReadData() -- backend closed the channel unexpectedly.
> 	This probably means the backend terminated abnormally before or while processing the request.
> We have lost the connection to the backend, so further processing is impossible.  Terminating.
> 
> Another things I'm troubled with are that some regression tests make
> the backend dump core on my LinuxPPC box.

I don't have this problem here.  However, the missing alignment on new
multi-key indexes may be the cause.  I am fixing that today.

> 
> $ grep -i pqread results/*
> 
> results/btree_index.out:pqReadData() -- backend closed the channel unexpectedly.
> results/constraints.out:pqReadData() -- backend closed the channel unexpectedly.
> results/create_function_1.out:pqReadData() -- backend closed the channel unexpectedly.
> results/create_function_2.out:pqReadData() -- backend closed the channel unexpectedly.
> results/sanity_check.out:pqReadData() -- backend closed the channel unexpectedly.
> results/select_views.out:pqReadData() -- backend closed the channel unexpectedly.
> results/triggers.out:pqReadData() -- backend closed the channel unexpectedly.
> 
> These were ok on FreeBSD except the sanity_check test(vacuum dumped
> core). I will look into these.
> --
> Tatsuo Ishii
> t-ishii@sra.co.jp
> 


-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Mon, 24 Aug 1998 10:19:32 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] initdb problem