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)

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)

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

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.

Another interesting thing?

(appologies for the width)

I would half expected attalign to be 'd' for all these.

I'm not sure how the values get there though!!

Keith.

template1=> select * from pg_attribute where attlen = 32;
attrelid|attname
|atttypid|attdisbursion|attlen|attnum|attnelems|attcacheoff|atttypmod|attbyval|a
ttisset|attalign|attnotnull|atthasdef
--------+-----------+--------+-------------+------+------+---------+-----------+
---------+--------+--------+--------+----------+---------
1247|typname | 19| 0| 32| 1| 0| -1|
-1|f |f |i |f |f
1262|datname | 19| 0| 32| 1| 0| -1|
-1|f |f |i |f |f
1255|proname | 19| 0| 32| 1| 0| -1|
-1|f |f |i |f |f
1255|proargtypes| 30| 0| 32| 10| 0| -1|
-1|f |f |i |f |f
1260|usename | 19| 0| 32| 1| 0| -1|
-1|f |f |i |f |f
1261|groname | 19| 0| 32| 1| 0| -1|
-1|f |f |i |f |f
1249|attname | 19| 0| 32| 2| 0| -1|
-1|f |f |i |f |f
1259|relname | 19| 0| 32| 1| 0| -1|
-1|f |f |i |f |f
1216|rcname | 19| 0| 32| 2| 0| -1|
-1|f |f |i |f |f
1219|tgname | 19| 0| 32| 2| 0| -1|
-1|f |f |i |f |f
16548|indclass | 30| 0| 32| 5| 0| -1|
-1|f |f |i |f |f
16590|oprname | 19| 0| 32| 1| 0| -1|
-1|f |f |d |f |f
16614|opcname | 19| 0| 32| 1| 0| -1|
-1|f |f |d |f |f
16624|amname | 19| 0| 32| 1| 0| -1|
-1|f |f |d |f |f
16869|lanname | 19| 0| 32| 1| 0| -1|
-1|f |f |d |f |f
16946|aggname | 19| 0| 32| 1| 0| -1|
-1|f |f |d |f |f
17013|inhproname | 19| 0| 32| 1| 0| -1|
-1|f |f |d |f |f
17025|rulename | 19| 0| 32| 1| 0| -1|
-1|f |f |d |f |f
17040|relname | 19| 0| 32| 1| 0| -1|
-1|f |f |d |f |f
17061|attname | 19| 0| 32| 2| 0| -1|
-1|f |f |i |f |f
17073|proname | 19| 0| 32| 1| 0| -1|
-1|f |f |i |f |f
17073|proargtypes| 30| 0| 32| 3| 0| -1|
-1|f |f |i |f |f
17082|typname | 19| 0| 32| 1| 0| -1|
-1|f |f |i |f |f
17088|relname | 19| 0| 32| 1| 0| -1|
-1|f |f |i |f |f
17184|usename | 19| 0| 32| 1| 0| -1|
-1|f |f |d |f |f
17248|rulename | 19| 0| 32| 1| 0| -1|
-1|f |f |d |f |f
17312|viewname | 19| 0| 32| 1| 0| -1|
-1|f |f |d |f |f

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)

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

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.

Another interesting thing?

(appologies for the width)

I would half expected attalign to be 'd' for all these.

I'm not sure how the values get there though!!

Can you research what the proper value should be. We have char/varchar
set to 'i', but others set to 'd'. What should be the proper value. Is
'd' and 'i' alignment the same on our supported platforms. Does a char
field of length 32 align on int, but a double align on double differently.

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

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

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.

Another interesting thing?

(appologies for the width)

I would half expected attalign to be 'd' for all these.

I'm not sure how the values get there though!!

Can you research what the proper value should be. We have char/varchar
set to 'i', but others set to 'd'. What should be the proper value. Is
'd' and 'i' alignment the same on our supported platforms. Does a char
field of length 32 align on int, but a double align on double differently.

Bruce,

I'm probably not the best person to explain this or determine what the
correct values are. I'm not sure I even understand how things work
myself.

I think we require the alignment definitions because we are storing
tuples as structures on disk and reading and writing them as raw
data. Hence, when we read from disk into one of the FormData structs
we need to ensure that the data reads in with the correct alignment.

(If you declare a struct in C it may occupy more bytes than you
imagine due to alignment.)

Reading by 'C' book here.

Don't assume, however, that the size of a structure is the sum
of the sizes of it's members. Because of alignment requirements
for different objects, there may be "holes" in a structure.
Thus, for instance, if a char is one bye and an int four bytes,
the structure

struct {
char c;
int i;
};

might well require eight bytes not five.

I guess we need to ensure that if we write this struct to disk we
put the bytes <char><pad><pad><pad><int><int><int><int> into the
block.

When we read the data back into the structure we get a valid alignment.

I think this padding works by adding bytes to the previous field so that
when the current field is written is is on the right boundary.

Does this make sense, or am I barking up the wrong tree?

Keith.

I think this padding works by adding bytes to the previous field so that
when the current field is written is is on the right boundary.

Does this make sense, or am I barking up the wrong tree?

You are correct. I just don't know what the alignment issues are of
double vs. int for our various character types.

This is more of an academic question, because your Sparc problem is
probably not that, but something else that I can reproduce 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)

I think this padding works by adding bytes to the previous field so that
when the current field is written is is on the right boundary.

Does this make sense, or am I barking up the wrong tree?

You are correct. I just don't know what the alignment issues are of
double vs. int for our various character types.

This is more of an academic question, because your Sparc problem is
probably not that, but something else that I can reproduce now.

--
Bruce Momjian | 830 Blythe Avenue

Hi all,

I don't know if this is really related to the initdb problem
discussion (haven't followed it enough). But seems so because
it fixes a damn problem during index tuple insertion on
CREATE TABLE into pg_attribute_relid_attnum_index.

Anyway - this bug was really hard to find. During startup the
relcache reads in some prepared information about index
strategies from a file and then reinitializes the function
pointers inside the scanKey data. But for sake it assumed
single attribute index tuples (hasn't that changed recently).
Thus not all the strategies scanKey entries where initialized
properly, resulting in invalid addresses for the btree
comparision functions.

With the patch at the end the regression tests passed
excellent except for the sanity_check that crashed at vacuum
and the misc test where the select unique1 from onek2 outputs
the two rows in different order.

Bruce, could you please apply it?

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #

*** relcache.c.orig	Fri Aug 28 05:03:02 1998
--- relcache.c	Fri Aug 28 05:02:12 1998
***************
*** 1982,1991 ****
  #define SMD(i)	strat[0].strategyMapData[i].entry[0]

/* have to reinit the function pointers in the strategy maps */
! for (i = 0; i < am->amstrategies; i++)
fmgr_info(SMD(i).sk_procedure,
&(SMD(i).sk_func));
! SMD(i).sk_nargs = SMD(i).sk_func.fn_nargs;

  		/*
--- 1982,1992 ----
  #define SMD(i)	strat[0].strategyMapData[i].entry[0]

/* have to reinit the function pointers in the strategy maps */
! for (i = 0; i < am->amstrategies * relform->relnatts; i++) {
fmgr_info(SMD(i).sk_procedure,
&(SMD(i).sk_func));
! SMD(i).sk_nargs = SMD(i).sk_func.fn_nargs;
! }

/*

Hi all,

I don't know if this is really related to the initdb problem
discussion (haven't followed it enough). But seems so because
it fixes a damn problem during index tuple insertion on
CREATE TABLE into pg_attribute_relid_attnum_index.

Anyway - this bug was really hard to find. During startup the
relcache reads in some prepared information about index
strategies from a file and then reinitializes the function
pointers inside the scanKey data. But for sake it assumed
single attribute index tuples (hasn't that changed recently).
Thus not all the strategies scanKey entries where initialized
properly, resulting in invalid addresses for the btree
comparision functions.

With the patch at the end the regression tests passed
excellent except for the sanity_check that crashed at vacuum
and the misc test where the select unique1 from onek2 outputs
the two rows in different order.

Bruce, could you please apply it?

Jan, this is great. It would have taken me a long time to find this.
Why my platform did not fail is a real mystery.

Patch applied. I am looking at the vacuum problem 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)

Jan, this is great. It would have taken me a long time to find this.
Why my platform did not fail is a real mystery.

Patch applied. I am looking at the vacuum problem now.

--
Bruce Momjian | 830 Blythe Avenue

Bruce,

Seems that the addresses that where assigned when
pg_internal.init is created (don't know exactly when this
happens) are the same as they should be later (when it is
read into). I absolutely don't know why they are different
between these two situations at all, it are all addresses
from builtin functions, and the postgres image is allways the
same one. So I'm a little confused about it. But these are
the facts gdb told me.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #