Thread: 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? Michael -- Michael Meskes meskes@online-club.de, meskes@debian.org Go SF49ers! Go Rhein Fire! Use Debian GNU/Linux!
> 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)
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!
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
==========================================================================
> 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)
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
> 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)
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
> 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)
>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
> >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)
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!
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!