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)

Bruce Momjian <maillist@candle.pha.pa.us>

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.

I have religously been doing a rm -rf data and initdb each time.

Keith.

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)

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!

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

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!

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)

Bruce,

It does not seem to be an initdb problem per se, as the initdb
proceeds normally and I end up with a database that works to some
extent.

If you have seen my recent posts and backtraces you will see that,
after initdb'ing, I connect to the template1 database and do a
"select * from pg_user;" is get an error.

template1=> select * from pg_user;
ERROR: Relation pg_user does not have attribute usename
template1=>

If I attempt to create a table I get a core dump.

It smells of an alignment problem (I'm on SPARC/Linux) as the
error is in a system call memmove() and the library call where
it bombs is _wordcopy_fwd_aligned ().

OK.

I have fixed the bootstrap process so it properly assignes attalign
values. It was not need with single-key indexes, but is needed now.

Also, I found many cases where system columns where missing
pg_attribute.attalign values. The values where ' '. The system has no
idea what to do with such a value.

Would someone check a running 6.3.2 system and let me know if there are
any blank attalign values? It think you will find that there are. The
current patch fixes that.

-- 
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 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 Mon, Aug 24, 1998 at 03:18:28PM -0400, Bruce Momjian wrote:

Would someone check a running 6.3.2 system and let me know if there are
any blank attalign values? It think you will find that there are. The
current patch fixes that.

echo "select * from pg_attribute where attalign != 'i' and attalign !=
'c'and attalign != 'd' and attalign!='s';"|psql template1

gives:

attrelid|attname |atttypid|attdisbursion|attlen|attnum|attnelems|attcacheoff|atttypmod|attbyval|attisset|attalign|attnotnull|atthasdef
--------+--------------+--------+-------------+------+------+---------+-----------+---------+--------+--------+--------+----------+---------
16536|inhrel | 26| 0| 4| 1| 0| -1| -1|t |f | |f |f
16536|inhparent | 26| 0| 4| 2| 0| -1| -1|t |f | |f |f
16536|inhseqno | 23| 0| 4| 3| 0| -1| -1|t |f | |f |f
16547|indexrelid | 26| 0| 4| 1| 0| -1| -1|t |f | |f |f
16547|indrelid | 26| 0| 4| 2| 0| -1| -1|t |f | |f |f
16547|indproc | 26| 0| 4| 3| 0| -1| -1|t |f | |f |f
16547|indkey | 22| 0| 16| 4| 0| -1| -1|f |f | |f |f
16547|indclass | 30| 0| 32| 5| 0| -1| -1|f |f | |f |f
16547|indisclustered| 16| 0| 1| 6| 0| -1| -1|t |f | |f |f
16547|indislossy | 16| 0| 1| 7| 0| -1| -1|t |f | |f |f
16547|indhaskeytype | 16| 0| 1| 8| 0| -1| -1|t |f | |f |f
16547|indisunique | 16| 0| 1| 9| 0| -1| -1|t |f | |f |f
16547|indpred | 25| 0| -1| 10| 0| -1| -1|f |f | |f |f
16565|verrelid | 26| 0| 4| 1| 0| -1| -1|t |f | |f |f
16565|verbaseid | 26| 0| 4| 2| 0| -1| -1|t |f | |f |f
16565|vertime | 23| 0| 4| 3| 0| -1| -1|t |f | |f |f
16577|starelid | 26| 0| 4| 1| 0| -1| -1|t |f | |f |f
16577|staattnum | 21| 0| 2| 2| 0| -1| -1|t |f | |f |f
16577|staop | 26| 0| 4| 3| 0| -1| -1|t |f | |f |f
16577|stalokey | 25| 0| -1| 4| 0| -1| -1|f |f | |f |f
16577|stahikey | 25| 0| -1| 5| 0| -1| -1|f |f | |f |f
16590|oprname | 19| 0| 32| 1| 0| -1| -1|f |f | |f |f
16590|oprowner | 26| 0| 4| 2| 0| -1| -1|t |f | |f |f
16590|oprprec | 21| 0| 2| 3| 0| -1| -1|t |f | |f |f
16590|oprkind | 18| 0| 1| 4| 0| -1| -1|t |f | |f |f
16590|oprisleft | 16| 0| 1| 5| 0| -1| -1|t |f | |f |f
16590|oprcanhash | 16| 0| 1| 6| 0| -1| -1|t |f | |f |f
16590|oprleft | 26| 0| 4| 7| 0| -1| -1|t |f | |f |f
16590|oprright | 26| 0| 4| 8| 0| -1| -1|t |f | |f |f
16590|oprresult | 26| 0| 4| 9| 0| -1| -1|t |f | |f |f
16590|oprcom | 26| 0| 4| 10| 0| -1| -1|t |f | |f |f
16590|oprnegate | 26| 0| 4| 11| 0| -1| -1|t |f | |f |f
16590|oprlsortop | 26| 0| 4| 12| 0| -1| -1|t |f | |f |f
16590|oprrsortop | 26| 0| 4| 13| 0| -1| -1|t |f | |f |f
16590|oprcode | 24| 0| 4| 14| 0| -1| -1|t |f | |f |f
16590|oprrest | 24| 0| 4| 15| 0| -1| -1|t |f | |f |f
16590|oprjoin | 24| 0| 4| 16| 0| -1| -1|t |f | |f |f
16614|opcname | 19| 0| 32| 1| 0| -1| -1|f |f | |f |f
16614|opcdeftype | 26| 0| 4| 2| 0| -1| -1|t |f | |f |f
16624|amname | 19| 0| 32| 1| 0| -1| -1|f |f | |f |f
16624|amowner | 26| 0| 4| 2| 0| -1| -1|t |f | |f |f
16624|amkind | 18| 0| 1| 3| 0| -1| -1|t |f | |f |f
16624|amstrategies | 21| 0| 2| 4| 0| -1| -1|t |f | |f |f
16624|amsupport | 21| 0| 2| 5| 0| -1| -1|t |f | |f |f
16624|amgettuple | 24| 0| 4| 6| 0| -1| -1|t |f | |f |f
16624|aminsert | 24| 0| 4| 7| 0| -1| -1|t |f | |f |f
16624|amdelete | 24| 0| 4| 8| 0| -1| -1|t |f | |f |f
16624|amgetattr | 24| 0| 4| 9| 0| -1| -1|t |f | |f |f
16624|amsetlock | 24| 0| 4| 10| 0| -1| -1|t |f | |f |f
16624|amsettid | 24| 0| 4| 11| 0| -1| -1|t |f | |f |f
16624|amfreetuple | 24| 0| 4| 12| 0| -1| -1|t |f | |f |f
16624|ambeginscan | 24| 0| 4| 13| 0| -1| -1|t |f | |f |f
16624|amrescan | 24| 0| 4| 14| 0| -1| -1|t |f | |f |f
16624|amendscan | 24| 0| 4| 15| 0| -1| -1|t |f | |f |f
16624|ammarkpos | 24| 0| 4| 16| 0| -1| -1|t |f | |f |f
16624|amrestrpos | 24| 0| 4| 17| 0| -1| -1|t |f | |f |f
16624|amopen | 24| 0| 4| 18| 0| -1| -1|t |f | |f |f
16624|amclose | 24| 0| 4| 19| 0| -1| -1|t |f | |f |f
16624|ambuild | 24| 0| 4| 20| 0| -1| -1|t |f | |f |f
16624|amcreate | 24| 0| 4| 21| 0| -1| -1|t |f | |f |f
16624|amdestroy | 24| 0| 4| 22| 0| -1| -1|t |f | |f |f
16654|amopid | 26| 0| 4| 1| 0| -1| -1|t |f | |f |f
16654|amopclaid | 26| 0| 4| 2| 0| -1| -1|t |f | |f |f
16654|amopopr | 26| 0| 4| 3| 0| -1| -1|t |f | |f |f
16654|amopstrategy | 21| 0| 2| 4| 0| -1| -1|t |f | |f |f
16654|amopselect | 24| 0| 4| 5| 0| -1| -1|t |f | |f |f
16654|amopnpages | 24| 0| 4| 6| 0| -1| -1|t |f | |f |f
16838|amid | 26| 0| 4| 1| 0| -1| -1|t |f | |f |f
16838|amopclaid | 26| 0| 4| 2| 0| -1| -1|t |f | |f |f
16838|amproc | 26| 0| 4| 3| 0| -1| -1|t |f | |f |f
16838|amprocnum | 21| 0| 2| 4| 0| -1| -1|t |f | |f |f
16901|lanname | 19| 0| 32| 1| 0| -1| -1|f |f | |f |f
16901|lanispl | 16| 0| 1| 2| 0| -1| -1|t |f | |f |f
16901|lanpltrusted | 16| 0| 1| 3| 0| -1| -1|t |f | |f |f
16901|lanplcallfoid | 26| 0| 4| 4| 0| -1| -1|t |f | |f |f
16901|lancompiler | 25| 0| -1| 5| 0| -1| -1|f |f | |f |f
16914|parproid | 26| 0| 4| 1| 0| -1| -1|t |f | |f |f
16914|parnum | 21| 0| 2| 2| 0| -1| -1|t |f | |f |f
16914|parbound | 18| 0| 1| 3| 0| -1| -1|t |f | |f |f
16914|partype | 26| 0| 4| 4| 0| -1| -1|t |f | |f |f
16978|aggname | 19| 0| 32| 1| 0| -1| -1|f |f | |f |f
16978|aggowner | 26| 0| 4| 2| 0| -1| -1|t |f | |f |f
16978|aggtransfn1 | 24| 0| 4| 3| 0| -1| -1|t |f | |f |f
16978|aggtransfn2 | 24| 0| 4| 4| 0| -1| -1|t |f | |f |f
16978|aggfinalfn | 24| 0| 4| 5| 0| -1| -1|t |f | |f |f
16978|aggbasetype | 26| 0| 4| 6| 0| -1| -1|t |f | |f |f
16978|aggtranstype1 | 26| 0| 4| 7| 0| -1| -1|t |f | |f |f
16978|aggtranstype2 | 26| 0| 4| 8| 0| -1| -1|t |f | |f |f
16978|aggfinaltype | 26| 0| 4| 9| 0| -1| -1|t |f | |f |f
16978|agginitval1 | 25| 0| -1| 10| 0| -1| -1|f |f | |f |f
16978|agginitval2 | 25| 0| -1| 11| 0| -1| -1|f |f | |f |f
17030|iplrel | 26| 0| 4| 1| 0| -1| -1|t |f | |f |f
17030|iplipl | 26| 0| 4| 2| 0| -1| -1|t |f | |f |f
17030|iplseqno | 23| 0| 4| 3| 0| -1| -1|t |f | |f |f
17041|inhproname | 19| 0| 32| 1| 0| -1| -1|f |f | |f |f
17041|inhargrel | 26| 0| 4| 2| 0| -1| -1|t |f | |f |f
17041|inhdefrel | 26| 0| 4| 3| 0| -1| -1|t |f | |f |f
17041|inhproc | 26| 0| 4| 4| 0| -1| -1|t |f | |f |f
17053|rulename | 19| 0| 32| 1| 0| -1| -1|f |f | |f |f
17053|ev_type | 18| 0| 1| 2| 0| -1| -1|t |f | |f |f
17053|ev_class | 26| 0| 4| 3| 0| -1| -1|t |f | |f |f
17053|ev_attr | 21| 0| 2| 4| 0| -1| -1|t |f | |f |f
17053|is_instead | 16| 0| 1| 5| 0| -1| -1|t |f | |f |f
17053|ev_qual | 25| 0| -1| 6| 0| -1| -1|f |f | |f |f
17053|ev_action | 25| 0| -1| 7| 0| -1| -1|f |f | |f |f
17068|relname | 19| 0| 32| 1| 0| -1| -1|f |f | |f |f
17068|listenerpid | 23| 0| 4| 2| 0| -1| -1|t |f | |f |f
17068|notification | 23| 0| 4| 3| 0| -1| -1|t |f | |f |f
17079|objoid | 26| 0| 4| 1| 0| -1| -1|t |f | |f |f
17079|description | 25| 0| -1| 2| 0| -1| -1|f |f | |f |f
17089|mkoidname | 911| 0| 36| 1| 0| -1| -1|f |f | |f |f
17092|mkoidint2 | 810| 0| 6| 1| 0| -1| -1|f |f | |f |f
17095|attrelid | 26| 0| 4| 1| 0| -1| -1|t |f | |f |f
17101|proname | 19| 0| 32| 1| 0| -1| -1|f |f | |f |f
17104|prosrc | 25| 0| -1| 1| 0| -1| -1|f |f | |f |f
17110|typname | 19| 0| 32| 1| 0| -1| -1|f |f | |f |f
17116|relname | 19| 0| 32| 1| 0| -1| -1|f |f | |f |f
17129|objoid | 26| 0| 4| 1| 0| -1| -1|t |f | |f |f
(118 rows)

EOF

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

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

On Mon, Aug 24, 1998 at 03:18:28PM -0400, Bruce Momjian wrote:

Would someone check a running 6.3.2 system and let me know if there are
any blank attalign values? It think you will find that there are. The
current patch fixes that.

echo "select * from pg_attribute where attalign != 'i' and attalign !=
'c'and attalign != 'd' and attalign!='s';"|psql template1

Yikes. Good thing that is fixed now.

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