> I am applying another patch to fix missing alignment information. 
> Please try this and let me know.
> 
> 
> > 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.

OK.  I did a little checking:
	
	#$ cd /pg/include/catalog/
	#$ grep 683 *.h
	#$ grep 682 *.h
	#$ grep 681 *.h
	pg_proc.h:DATA(insert OID = 681 (  oid8gt                          PGUID
	11 f t f 2 f 16 "30 30" 100 0 0 100  foo bar ));

	#$ sql test
	seleWelcome to the POSTGRESQL interactive sql monitor:
	  Please read the file COPYRIGHT for copyright terms of POSTGRESQL
	
	   type \? for help on slash commands
	   type \q to quit
	   type \g or terminate with semicolon to execute query
	 You are currently connected to the database: test
	
	ctest=> select * from pg_proc where oid = 683
	test-> \g
	proname|proowner|prolang|proisinh|proistrusted|proiscachable|pronargs|proretset|prorettype|proargtypes|probyte_pct|properbyte_cpu|propercall_cpu|prooutin_ratio|prosrc|probin
	-------+--------+-------+--------+------------+-------------+--------+---------+----------+-----------+-----------+--------------+--------------+--------------+------+------
	(0 rows)


Your system is complaining about a lookup of 683.  Part of the problem
is that there is no reference to that number in the system catalog
stuff, nor on my running system.  Now I will say that 681 is one of the
new functions I added to allow indexing of the oid8 field.  My guess is
that somewhere you have something with that number in your source, and
it should not be there.

Try reproducing my 'grep' and see if you get anything.  If you do, the
somehow you have an old copy of the source.

-- 
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)

Tue, 25 Aug 1998 00:53:21 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] initdb problem
I should be clear.  This 'grep' was done in pgsql/src/include/catalog
directory.

> OK.  I did a little checking:
> 	
> 	#$ cd /pg/include/catalog/
> 	#$ grep 683 *.h
> 	#$ grep 682 *.h
> 	#$ grep 681 *.h
> 	pg_proc.h:DATA(insert OID = 681 (  oid8gt                          PGUID
> 	11 f t f 2 f 16 "30 30" 100 0 0 100  foo bar ));
> 
> 	#$ sql test
> 	seleWelcome to the POSTGRESQL interactive sql monitor:
> 	  Please read the file COPYRIGHT for copyright terms of POSTGRESQL
> 	
> 	   type \? for help on slash commands
> 	   type \q to quit
> 	   type \g or terminate with semicolon to execute query
> 	 You are currently connected to the database: test
> 	
> 	ctest=> select * from pg_proc where oid = 683
> 	test-> \g
> 	proname|proowner|prolang|proisinh|proistrusted|proiscachable|pronargs|proretset|prorettype|proargtypes|probyte_pct|properbyte_cpu|propercall_cpu|prooutin_ratio|prosrc|probin
> 	-------+--------+-------+--------+------------+-------------+--------+---------+----------+-----------+-----------+--------------+--------------+--------------+------+------
> 	(0 rows)
> 
> 
> Your system is complaining about a lookup of 683.  Part of the problem
> is that there is no reference to that number in the system catalog
> stuff, nor on my running system.  Now I will say that 681 is one of the
> new functions I added to allow indexing of the oid8 field.  My guess is
> that somewhere you have something with that number in your source, and
> it should not be there.
> 
> Try reproducing my 'grep' and see if you get anything.  If you do, the
> somehow you have an old copy of the source.
> 
> -- 
> 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 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)

Tue, 25 Aug 1998 01:02:36 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] initdb problem
On Tue, Aug 25, 1998 at 12:53:21AM -0400, Bruce Momjian wrote:
> OK.  I did a little checking:
> 	
> 	#$ cd /pg/include/catalog/
> 	#$ grep 683 *.h
> 	#$ grep 682 *.h
> 	#$ grep 681 *.h
> 	pg_proc.h:DATA(insert OID = 681 (  oid8gt                          PGUID
> 	11 f t f 2 f 16 "30 30" 100 0 0 100  foo bar ));

Exactly the same results for me.

> 	#$ sql test
> 	seleWelcome to the POSTGRESQL interactive sql monitor:
> 	  Please read the file COPYRIGHT for copyright terms of POSTGRESQL
> 	
> 	   type \? for help on slash commands
> 	   type \q to quit
> 	   type \g or terminate with semicolon to execute query
> 	 You are currently connected to the database: test
> 	
> 	ctest=> select * from pg_proc where oid = 683
> 	test-> \g
> 	proname|proowner|prolang|proisinh|proistrusted|proiscachable|pronargs|proretset|prorettype|proargtypes|probyte_pct|properbyte_cpu|propercall_cpu|prooutin_ratio|prosrc|probin
> 	-------+--------+-------+--------+------------+-------------+--------+---------+----------+-----------+-----------+--------------+--------------+--------------+------+------
> 	(0 rows)

Cannot check that since it is initdb that fails.

> that somewhere you have something with that number in your source, and
> it should not be there.

I grep through the whole source tree and all I found is:

#define F_OID8EQ 683

in ./include/fmgr.h

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

Tue, 25 Aug 1998 14:28:01 +0200
Michael Meskes <meskes@online-club.de>
Re: [HACKERS] initdb problem
> On Tue, Aug 25, 1998 at 12:53:21AM -0400, Bruce Momjian wrote:
> > OK.  I did a little checking:
> > 	
> > 	#$ cd /pg/include/catalog/
> > 	#$ grep 683 *.h
> > 	#$ grep 682 *.h
> > 	#$ grep 681 *.h
> > 	pg_proc.h:DATA(insert OID = 681 (  oid8gt                          PGUID
> > 	11 f t f 2 f 16 "30 30" 100 0 0 100  foo bar ));
> 
> Exactly the same results for me.
> 
> > 	#$ sql test
> > 	seleWelcome to the POSTGRESQL interactive sql monitor:
> > 	  Please read the file COPYRIGHT for copyright terms of POSTGRESQL
> > 	
> > 	   type \? for help on slash commands
> > 	   type \q to quit
> > 	   type \g or terminate with semicolon to execute query
> > 	 You are currently connected to the database: test
> > 	
> > 	ctest=> select * from pg_proc where oid = 683
> > 	test-> \g
> > 	proname|proowner|prolang|proisinh|proistrusted|proiscachable|pronargs|proretset|prorettype|proargtypes|probyte_pct|properbyte_cpu|propercall_cpu|prooutin_ratio|prosrc|probin
> > 	-------+--------+-------+--------+------------+-------------+--------+---------+----------+-----------+-----------+--------------+--------------+--------------+------+------
> > 	(0 rows)
> 
> Cannot check that since it is initdb that fails.
> 
> > that somewhere you have something with that number in your source, and
> > it should not be there.
> 
> I grep through the whole source tree and all I found is:
> 
> #define F_OID8EQ 683
> 
> in ./include/fmgr.h

That is the problem.  I don't have an fmgr.h file in include, just in
backend/fmgr.h.  It is finding an old one first.  It was not a problem
as long as no one made changes to the system tables, but I did.

That is why the clean cvsup worked for people.  How the fmgr.h file got
into include, I have no idea.

The only 683 I get from the source are labels in gram.c.

Remove the file and recompile.

-- 
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)

Tue, 25 Aug 1998 13:45:33 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] initdb problem
On Tue, Aug 25, 1998 at 01:45:33PM -0400, Bruce Momjian wrote:
> That is the problem.  I don't have an fmgr.h file in include, just in
> backend/fmgr.h.  It is finding an old one first.  It was not a problem
> as long as no one made changes to the system tables, but I did.
> 
> That is why the clean cvsup worked for people.  How the fmgr.h file got
> into include, I have no idea.
> 
> The only 683 I get from the source are labels in gram.c.
> 
> Remove the file and recompile.

I did and it works! Thanks a lot. I also tried the ecpg examples. Two ran
fine, but the perftest.pgc example gets:

postgres@feivel:~/pgsql/src/interfaces/ecpg.mm/test$ ./perftest
I needed 14 seconds and 618584 microseconds for the insert test.
sql error Error: ERROR: fmgr_info: function 28261: cache lookup failed

 line 19.

line 19 is exec sql vacuum.

BTW the UNLISTEN symbol is undefined in gram.y and here's a minor patch to
be able to compile ecpg:

diff -rc ecpg/preproc/preproc.y ecpg.mm/preproc/preproc.y
*** ecpg/preproc/preproc.y      Wed Aug 26 06:42:50 1998
--- ecpg.mm/preproc/preproc.y   Wed Aug 26 08:17:24 1998
***************
*** 641,647 ****
  %type  <str>  join_using where_clause relation_expr row_op sub_type
  %type  <str>  opt_column_list insert_rest InsertStmt OptimizableStmt
  %type  <str>    columnList DeleteStmt LockStmt UpdateStmt CursorStmt
! %type  <str>    NotifyStmt columnElem copy_dirn SubUnion c_expr
  %type  <str>    copy_delimiter ListenStmt CopyStmt copy_file_name opt_binary
  %type  <str>    opt_with_copy FetchStmt opt_direction fetch_how_many opt_portal_name
  %type  <str>    ClosePortalStmt DestroyStmt VacuumStmt opt_verbose
--- 641,647 ----
  %type  <str>  join_using where_clause relation_expr row_op sub_type
  %type  <str>  opt_column_list insert_rest InsertStmt OptimizableStmt
  %type  <str>    columnList DeleteStmt LockStmt UpdateStmt CursorStmt
! %type  <str>    NotifyStmt columnElem copy_dirn SubUnion c_expr UnlistenStmt
  %type  <str>    copy_delimiter ListenStmt CopyStmt copy_file_name opt_binary
  %type  <str>    opt_with_copy FetchStmt opt_direction fetch_how_many opt_portal_name
  %type  <str>    ClosePortalStmt DestroyStmt VacuumStmt opt_verbose

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

Wed, 26 Aug 1998 08:35:04 +0200
Michael Meskes <meskes@online-club.de>
Re: [HACKERS] initdb problem
> On Tue, Aug 25, 1998 at 01:45:33PM -0400, Bruce Momjian wrote:
> > That is the problem.  I don't have an fmgr.h file in include, just in
> > backend/fmgr.h.  It is finding an old one first.  It was not a problem
> > as long as no one made changes to the system tables, but I did.
> > 
> > That is why the clean cvsup worked for people.  How the fmgr.h file got
> > into include, I have no idea.
> > 
> > The only 683 I get from the source are labels in gram.c.
> > 
> > Remove the file and recompile.
> 
> I did and it works! Thanks a lot. I also tried the ecpg examples. Two ran
> fine, but the perftest.pgc example gets:
> 
> postgres@feivel:~/pgsql/src/interfaces/ecpg.mm/test$ ./perftest
> I needed 14 seconds and 618584 microseconds for the insert test.
> sql error Error: ERROR: fmgr_info: function 28261: cache lookup failed
> 
>  line 19.
> 
> line 19 is exec sql vacuum.
> 
> BTW the UNLISTEN symbol is undefined in gram.y and here's a minor patch to
> be able to compile ecpg:

Patch applied.  I just did a grep, and not 28261 was not found in
/pgsql/src/include/catalog, so I assume some old binary is refering to
it.



-- 
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)

Wed, 26 Aug 1998 12:37:27 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] initdb problem