Thread: Re: [HACKERS] initdb problem
> 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)
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)
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!
> 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)
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!
> 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)