Core dump in regression tests.

Hi, yes, I'm having trouble as well.

I'm crashing anytime I create a table, (-O2). I just tried the 8/29 snapshot.
I've got an environment set up now to try a few things.

Without -O2 it seem to be better. I see the same problem with
create function as you. Also many failures seem to the result
of some type not defined. Is that expected?

Sorry to jump in so late here.

Tom Szybist
szybist@boxhill.com

In message <199808291829.TAA25332@mtcc.demon.co.uk>, Keith Parks writes:

Thomas A. Szybist <szybist@boxhill.com>

Hi, yes, I'm having trouble as well.

Sorry to hear that but I don't feel quite so alone now ;-)

I'm crashing anytime I create a table, (-O2). I just tried the 8/29 snapshot.
I've got an environment set up now to try a few things.

Same thing here with -O2, I think some of the other pg_user, pg_view etc.
problems all boil down to table creation as those are created as
tables after bootstrapping and subsequently converted to views.

Without -O2 it seem to be better. I see the same problem with
create function as you. Also many failures seem to the result
of some type not defined. Is that expected?

Yes, there are many problems in the regression tests due to some
type removal, I think, by Bruce. We're just waiting for the
regression test "expected" results to catch up.

Sorry to jump in so late here.

Better late than never <grin>

Just out of interest, what platform are you running on?
(S/Linux on an SUN IPX here)

Keith.

In message <199808292119.WAA27374@mtcc.demon.co.uk>, Keith Parks writes:

Thomas A. Szybist <szybist@boxhill.com>

Hi, yes, I'm having trouble as well.

Sorry to hear that but I don't feel quite so alone now ;-)

Misery loves company :).

I'm crashing anytime I create a table, (-O2). I just tried the 8/29 snapshot.
I've got an environment set up now to try a few things.

Same thing here with -O2, I think some of the other pg_user, pg_view etc.
problems all boil down to table creation as those are created as
tables after bootstrapping and subsequently converted to views.

Without -O2 it seem to be better. I see the same problem with
create function as you. Also many failures seem to the result
of some type not defined. Is that expected?

Yes, there are many problems in the regression tests due to some
type removal, I think, by Bruce. We're just waiting for the
regression test "expected" results to catch up.

Sorry to jump in so late here.

Better late than never <grin>

Just out of interest, what platform are you running on?
(S/Linux on an SUN IPX here)

Keith.

This is on a Red Hat 4.1 (Yes 4.1) system. Thing is, it's a production
system, and I haven't reason to upgrade.

Kernel is 2.0.29 gcc 2.7.2.1. Sparc 20.

I was toying with the idea of tossing Red Had 5.1 on a sparc classic,
to see if glibc on S/Linux hoses anything.

Tom Szybist
szybist@boxhill.com

In message <199808292119.WAA27374@mtcc.demon.co.uk>, Keith Parks writes:

Thomas A. Szybist <szybist@boxhill.com>

Hi, yes, I'm having trouble as well.

Sorry to hear that but I don't feel quite so alone now ;-)

Misery loves company :).

I'm crashing anytime I create a table, (-O2). I just tried the 8/29 snapshot.
I've got an environment set up now to try a few things.

Same thing here with -O2, I think some of the other pg_user, pg_view etc.
problems all boil down to table creation as those are created as
tables after bootstrapping and subsequently converted to views.

Without -O2 it seem to be better. I see the same problem with
create function as you. Also many failures seem to the result
of some type not defined. Is that expected?

Yes, there are many problems in the regression tests due to some
type removal, I think, by Bruce. We're just waiting for the
regression test "expected" results to catch up.

Sorry to jump in so late here.

Better late than never <grin>

Just out of interest, what platform are you running on?
(S/Linux on an SUN IPX here)

Keith.

This is on a Red Hat 4.1 (Yes 4.1) system. Thing is, it's a production
system, and I haven't reason to upgrade.

Kernel is 2.0.29 gcc 2.7.2.1. Sparc 20.

I was toying with the idea of tossing Red Had 5.1 on a sparc classic,
to see if glibc on S/Linux hoses anything.

Again, if someone wants to conditionally compile the directories to find
the offending file, I am sure we can get a fix for 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)

In message <199808300008.UAA15993@candle.pha.pa.us>, Bruce Momjian writes:

In message <199808292119.WAA27374@mtcc.demon.co.uk>, Keith Parks writes:

Thomas A. Szybist <szybist@boxhill.com>

Hi, yes, I'm having trouble as well.

Sorry to hear that but I don't feel quite so alone now ;-)

Misery loves company :).

I'm crashing anytime I create a table, (-O2). I just tried the 8/29 snapshot.
I've got an environment set up now to try a few things.

Same thing here with -O2, I think some of the other pg_user, pg_view etc.
problems all boil down to table creation as those are created as
tables after bootstrapping and subsequently converted to views.

Without -O2 it seem to be better. I see the same problem with
create function as you. Also many failures seem to the result
of some type not defined. Is that expected?

Yes, there are many problems in the regression tests due to some
type removal, I think, by Bruce. We're just waiting for the
regression test "expected" results to catch up.

Sorry to jump in so late here.

Better late than never <grin>

Just out of interest, what platform are you running on?
(S/Linux on an SUN IPX here)

Keith.

This is on a Red Hat 4.1 (Yes 4.1) system. Thing is, it's a production
system, and I haven't reason to upgrade.

Kernel is 2.0.29 gcc 2.7.2.1. Sparc 20.

I was toying with the idea of tossing Red Had 5.1 on a sparc classic,
to see if glibc on S/Linux hoses anything.

Again, if someone wants to conditionally compile the directories to find
the offending file, I am sure we can get a fix for 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)

At first look it seems to be: backend/catalog/indexing.c.
Maybe Keith can confirm?

Thanks,

Tom Szybist
szybist@boxhill.com

I built and run the regression tests from a clean cvs tree this morning
(1998-08-30 20:00UTC). I have removed the oidint2, oidint4, and oidname
tests since the types no longer exist, and have updated alter_table to
remove mention of these types. I've committed these changes to the cvs
tree.

There are some failures (itemized below). The only failure I saw before
the big OID patch-fest was select_views.

So, the current status on my system (i686, Linux 2.0.30, RedHat 4.2, -O2
optimization enabled) is that all tests pass except the following:

- constraints .. failed
Core dump.

- create_index .. failed
Fails on all create index statements after the first one with the
message:
QUERY: CREATE INDEX onek_unique2 ON onek USING btree(unique2 int4_ops);
ERROR: DefineIndex: onek relation not found
but, this statement executes just fine after the regression tests have
completed and I connect in from another process:
regression=> CREATE INDEX onek_unique2 ON onek USING btree(unique2
int4_ops);
CREATE
Is it a cache problem somewhere??

sanity_check .. failed

NOTICE: Index pg_class_relname_index: NUMBER OF INDEX' TUPLES (144) IS NOT THE SAME AS HEAP' (135)
NOTICE: Index pg_class_oid_index: NUMBER OF INDEX' TUPLES (144) IS NOT THE SAME AS HEAP' (135)

These warnings weren't present before. Also sensitive to missing table
from constraints test failure.

select_having .. failed
Core dump.

select_views .. failed
Core dump. afaik this has been present for a month or two, and is a
failure on the last query in the test. EXPLAIN shows a valid result, so
the crash happens farther back.

run_ruletest .. failed
Apparently not critical; the test depends on the name of the dba being
"pgsql" and my system has a dba named "postgres". The test should be
fixed for v6.4.

- Tom

Thomas A. Szybist" <szybist@boxhill.com>

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

Again, if someone wants to conditionally compile the directories to find
the offending file, I am sure we can get a fix for it.

At first look it seems to be: backend/catalog/indexing.c.
Maybe Keith can confirm?

Thanks,

Tom,

I recompiled the latest cvs with -O2 and found that the crash on
table creation was NOT now failing so I'm a little confused :-(

I'm just updating my cvs, and will do another build and see how
things go.

If only I had the same failures as before I'd be able to confirm
your suspicions on indexing.c

Til Later,
Keith.

Thomas A. Szybist" <szybist@boxhill.com>

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

Again, if someone wants to conditionally compile the directories to find
the offending file, I am sure we can get a fix for it.

At first look it seems to be: backend/catalog/indexing.c.
Maybe Keith can confirm?

Thanks,

Tom,

I recompiled the latest cvs with -O2 and found that the crash on
table creation was NOT now failing so I'm a little confused :-(

I'm just updating my cvs, and will do another build and see how
things go.

If only I had the same failures as before I'd be able to confirm
your suspicions on indexing.c

I have found a problem in indexing.c. In CatalogIndexFetchTuple(),
there is a particulary weird do..while loop, and in trying to clean it
up as part of the megapatch, I broke it and thought I had it fixed.

It appears it may still be broken. The ReleaseBuffer(buffer) call could
happen even if no valid tuple is returned because buffer has a random
value.

I am running a test now, and will post the fix as soon as I am sure it
works.

-- 
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 recompiled the latest cvs with -O2 and found that the crash on
table creation was NOT now failing so I'm a little confused :-(

I'm just updating my cvs, and will do another build and see how
things go.

If only I had the same failures as before I'd be able to confirm
your suspicions on indexing.c

Til Later,
Keith.

OK, I am applying my patch now. I certainly fixes a potential problem,
so I suspect it will fix the problems you are seeing.

Thomas, perhaps it will fix the regression problems too. No way to
know.

Here is the new while loop. Much better.

---------------------------------------------------------------------------

sd = index_beginscan(idesc, false, num_keys, skey);
while (indexRes = index_getnext(sd, ForwardScanDirection))
{
ItemPointer iptr;

iptr = &indexRes->heap_iptr;
tuple = heap_fetch(heapRelation, SnapshotNow, iptr, &buffer);
pfree(indexRes);
if (HeapTupleIsValid(tuple))
break;
}

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

Thomas G. Lockhart wrote:

select_having .. failed
Core dump.

My bad. It is caused by a known bug having to do with GROUP BY. It ain't a good bug, but it has
nothing to do with HAVING. For some reason the bug went away for a while, while I was building the test
script. It must have, because that is how I created the expected file. :(

A patch to the regression will be forthcoming.

Thomas, I have just run the regression test here with my indexing.c
patch, and the only serious errors I see are the cases that have already
been mentioned like the having core dump, and the postgres/pgsql rule
difference.

Do you still see other differences? Let me know.

I am putting the two spaces after an elog message back in because I
don't think we want to change that format for no good reason.

I can see people expecting the string to look a certain way.

I built and run the regression tests from a clean cvs tree this morning
(1998-08-30 20:00UTC). I have removed the oidint2, oidint4, and oidname
tests since the types no longer exist, and have updated alter_table to
remove mention of these types. I've committed these changes to the cvs
tree.

There are some failures (itemized below). The only failure I saw before
the big OID patch-fest was select_views.

So, the current status on my system (i686, Linux 2.0.30, RedHat 4.2, -O2
optimization enabled) is that all tests pass except the following:

- constraints .. failed
Core dump.

- create_index .. failed
Fails on all create index statements after the first one with the
message:
QUERY: CREATE INDEX onek_unique2 ON onek USING btree(unique2 int4_ops);
ERROR: DefineIndex: onek relation not found
but, this statement executes just fine after the regression tests have
completed and I connect in from another process:
regression=> CREATE INDEX onek_unique2 ON onek USING btree(unique2
int4_ops);
CREATE
Is it a cache problem somewhere??

sanity_check .. failed

NOTICE: Index pg_class_relname_index: NUMBER OF INDEX' TUPLES (144) IS NOT THE SAME AS HEAP' (135)
NOTICE: Index pg_class_oid_index: NUMBER OF INDEX' TUPLES (144) IS NOT THE SAME AS HEAP' (135)

These warnings weren't present before. Also sensitive to missing table
from constraints test failure.

select_having .. failed
Core dump.

select_views .. failed
Core dump. afaik this has been present for a month or two, and is a
failure on the last query in the test. EXPLAIN shows a valid result, so
the crash happens farther back.

run_ruletest .. failed
Apparently not critical; the test depends on the name of the dba being
"pgsql" and my system has a dba named "postgres". The test should be
fixed for v6.4.

- Tom

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

In message <199808302324.TAA28018@candle.pha.pa.us>, Bruce Momjian writes:

I recompiled the latest cvs with -O2 and found that the crash on
table creation was NOT now failing so I'm a little confused :-(

I'm just updating my cvs, and will do another build and see how
things go.

If only I had the same failures as before I'd be able to confirm
your suspicions on indexing.c

Til Later,
Keith.

OK, I am applying my patch now. I certainly fixes a potential problem,
so I suspect it will fix the problems you are seeing.

Thomas, perhaps it will fix the regression problems too. No way to
know.

Here is the new while loop. Much better.

---------------------------------------------------------------------------

sd = index_beginscan(idesc, false, num_keys, skey);
while (indexRes = index_getnext(sd, ForwardScanDirection))
{
ItemPointer iptr;

iptr = &indexRes->heap_iptr;
tuple = heap_fetch(heapRelation, SnapshotNow, iptr, &buffer);
pfree(indexRes);
if (HeapTupleIsValid(tuple))
break;
}

-- 
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 tried patching indexing.c with this new loop--no luck. I just
checked out a fresh copy, still no luck. I don't understand why it now
works for Keith.

Yesterday I tried this on Solaris, but I was bitten by not having
flock.

Tom Szybist
szybist@boxhill.com

Thomas A. Szybist" <szybist@boxhill.com>

Bruce Momjian

Again, if someone wants to conditionally compile the directories to find
the offending file, I am sure we can get a fix for it.

At first look it seems to be: backend/catalog/indexing.c.
Maybe Keith can confirm?

With the latest from cvs the core dump on "create table" is back
when compiled with -O2.

If I compile backend/catalog with -O2 then the table creation is
OK. So it looks like it may be indexing.c, even with Bruce's
recent fixes.

I'm still getting some regression test failures, the worst of which
is a core when creating a function.

Here's a bactrace from a "create function" immediately after an initdb
and using the template1 database.

Keith.

Program received signal SIGSEGV, Segmentation fault.
0x34264 in GetIndexValue (tuple=0x1ba810, hTupDesc=0x1ba86c, attOff=0,
attrNums=0x1bd544, fInfo=0x0,
attNull=0xefffcc97 "") at indexam.c:404
404 returnVal = heap_getattr(tuple, attrNums[attOff],
(gdb) bt
#0 0x34264 in GetIndexValue (tuple=0x1ba810, hTupDesc=0x1ba86c, attOff=0,
attrNums=0x1bd544, fInfo=0x0,
attNull=0xefffcc97 "") at indexam.c:404
#1 0x4974c in FormIndexDatum (numberOfAttributes=1, attributeNumber=0x1bd544,
heapTuple=0x1ba810,
heapDescriptor=0x1ba86c, datum=0xefffcd80, nullv=0xefffcd20 " \230",
fInfo=0x0) at index.c:1284
#2 0x4a4e8 in CatalogIndexInsert (idescs=0xefffcdf8, nIndices=3,
heapRelation=0x171b90, heapTuple=0x1ba810)
at indexing.c:154
#3 0x4fb2c in ProcedureCreate (procedureName=0x166bf0 "widget_in", returnsSet=0
'\000',
returnTypeName=0x166bb0 "widget", languageName=0xefffcf98 "C",
prosrc=0xeb800 "-",
probin=0x1aeb10 "/usr/local/pgsql/src/test/regress/input/../regress.so",
canCache=112 'p',
trusted=1 '\001', byte_pct=100, perbyte_cpu=0, percall_cpu=0,
outin_ratio=100, argList=0x166bd0,
dest=Remote) at pg_proc.c:275
#4 0x55674 in CreateFunction (stmt=0x165a50, dest=Remote) at define.c:329
#5 0xb8430 in ProcessUtility (parsetree=0x165a50, dest=Remote) at utility.c:392
#6 0xb60f8 in pg_exec_query_dest (
query_string=0xefffd1a0 "CREATE FUNCTION widget_in(opaque)\n RETURNS
widget\n AS '/usr/local/pgsql/src/test/regress/input/../regress.so'\n
LANGUAGE 'c';", dest=Remote, aclOverride=0 '\000') at postgres.c:749
#7 0xb5fec in pg_exec_query (
query_string=0xefffd1a0 "CREATE FUNCTION widget_in(opaque)\n RETURNS
widget\n AS '/usr/local/pgsql/src/test/regress/input/../regress.so'\n
LANGUAGE 'c';") at postgres.c:687
#8 0xb72ec in PostgresMain (argc=10, argv=0xeffff268, real_argc=10,
real_argv=0xeffffd84) at postgres.c:1609
#9 0x9f27c in DoBackend (port=0x107c00) at postmaster.c:1519
#10 0x9ecf4 in BackendStartup (port=0x167c00) at postmaster.c:1291
#11 0x9e16c in ServerLoop () at postmaster.c:750
#12 0x9dcc4 in PostmasterMain (argc=0, argv=0xeffffd84) at postmaster.c:556
#13 0x723b0 in main (argc=10, argv=0xeffffd84) at main.c:93

In message <199808311703.SAA29362@mtcc.demon.co.uk>, Keith Parks writes:

Thomas A. Szybist" <szybist@boxhill.com>

Bruce Momjian

Again, if someone wants to conditionally compile the directories to find
the offending file, I am sure we can get a fix for it.

At first look it seems to be: backend/catalog/indexing.c.
Maybe Keith can confirm?

With the latest from cvs the core dump on "create table" is back
when compiled with -O2.

If I compile backend/catalog with -O2 then the table creation is

^^^

OK. So it looks like it may be indexing.c, even with Bruce's
recent fixes.

Do you mean -O0 here?

I'm still getting some regression test failures, the worst of which
is a core when creating a function.

Here's a bactrace from a "create function" immediately after an initdb
and using the template1 database.

Keith.

Program received signal SIGSEGV, Segmentation fault.
0x34264 in GetIndexValue (tuple=0x1ba810, hTupDesc=0x1ba86c, attOff=0,
attrNums=0x1bd544, fInfo=0x0,
attNull=0xefffcc97 "") at indexam.c:404
404 returnVal = heap_getattr(tuple, attrNums[attOff],
(gdb) bt
#0 0x34264 in GetIndexValue (tuple=0x1ba810, hTupDesc=0x1ba86c, attOff=0,
attrNums=0x1bd544, fInfo=0x0,
attNull=0xefffcc97 "") at indexam.c:404
#1 0x4974c in FormIndexDatum (numberOfAttributes=1, attributeNumber=0x1bd544,
heapTuple=0x1ba810,
heapDescriptor=0x1ba86c, datum=0xefffcd80, nullv=0xefffcd20 " \230",
fInfo=0x0) at index.c:1284
#2 0x4a4e8 in CatalogIndexInsert (idescs=0xefffcdf8, nIndices=3,
heapRelation=0x171b90, heapTuple=0x1ba810)
at indexing.c:154
#3 0x4fb2c in ProcedureCreate (procedureName=0x166bf0 "widget_in", returnsSet=0
'\000',
returnTypeName=0x166bb0 "widget", languageName=0xefffcf98 "C",
prosrc=0xeb800 "-",
probin=0x1aeb10 "/usr/local/pgsql/src/test/regress/input/../regress.so",
canCache=112 'p',
trusted=1 '\001', byte_pct=100, perbyte_cpu=0, percall_cpu=0,
outin_ratio=100, argList=0x166bd0,
dest=Remote) at pg_proc.c:275
#4 0x55674 in CreateFunction (stmt=0x165a50, dest=Remote) at define.c:329
#5 0xb8430 in ProcessUtility (parsetree=0x165a50, dest=Remote) at utility.c:392
#6 0xb60f8 in pg_exec_query_dest (
query_string=0xefffd1a0 "CREATE FUNCTION widget_in(opaque)\n RETURNS
widget\n AS '/usr/local/pgsql/src/test/regress/input/../regress.so'\n
LANGUAGE 'c';", dest=Remote, aclOverride=0 '\000') at postgres.c:749
#7 0xb5fec in pg_exec_query (
query_string=0xefffd1a0 "CREATE FUNCTION widget_in(opaque)\n RETURNS
widget\n AS '/usr/local/pgsql/src/test/regress/input/../regress.so'\n
LANGUAGE 'c';") at postgres.c:687
#8 0xb72ec in PostgresMain (argc=10, argv=0xeffff268, real_argc=10,
real_argv=0xeffffd84) at postgres.c:1609
#9 0x9f27c in DoBackend (port=0x107c00) at postmaster.c:1519
#10 0x9ecf4 in BackendStartup (port=0x167c00) at postmaster.c:1291
#11 0x9e16c in ServerLoop () at postmaster.c:750
#12 0x9dcc4 in PostmasterMain (argc=0, argv=0xeffffd84) at postmaster.c:556
#13 0x723b0 in main (argc=10, argv=0xeffffd84) at main.c:93

I managed to get this running on a Solaris box. -O2 was not included
by default (wonder why :)). I got a core dump when running initdb
with -O2. I recompiled indexing.c without -O2, and it is much better.
(I basically get the same results as under Linux.) I get the same
core dumps that Keith is seeing with create function.

So, both my Sparc boxes are behaving the same.

Tom Szybist
szybist@boxhill.com

Thomas A. Szybist" <szybist@boxhill.com>

Bruce Momjian

Again, if someone wants to conditionally compile the directories to find
the offending file, I am sure we can get a fix for it.

At first look it seems to be: backend/catalog/indexing.c.
Maybe Keith can confirm?

With the latest from cvs the core dump on "create table" is back
when compiled with -O2.

If I compile backend/catalog with -O2 then the table creation is
OK. So it looks like it may be indexing.c, even with Bruce's
recent fixes.

Do you mean -O0 here?

I'm still getting some regression test failures, the worst of which
is a core when creating a function.

Here's a bactrace from a "create function" immediately after an initdb
and using the template1 database.

I have looked over indexing.c and can still see nothing strange. I do
remember that ProcedureSrcIndexScan/PROSRC cache call never worked in
the old code, so this call is now working, but that is the only
functional difference I remember.

The old code in this section was somewhat mangled.

Can I telnet into this machine?

Keith.

Program received signal SIGSEGV, Segmentation fault.
0x34264 in GetIndexValue (tuple=0x1ba810, hTupDesc=0x1ba86c, attOff=0,
attrNums=0x1bd544, fInfo=0x0,
attNull=0xefffcc97 "") at indexam.c:404
404 returnVal = heap_getattr(tuple, attrNums[attOff],
(gdb) bt
#0 0x34264 in GetIndexValue (tuple=0x1ba810, hTupDesc=0x1ba86c, attOff=0,
attrNums=0x1bd544, fInfo=0x0,

My guess is that hTupDesc is badly formed, not having the proper
attributes for the relation. Can you do a print of *hTupDesc, and
attrNums[0]?

attNull=0xefffcc97 "") at indexam.c:404
#1 0x4974c in FormIndexDatum (numberOfAttributes=1, attributeNumber=0x1bd544,
heapTuple=0x1ba810,
heapDescriptor=0x1ba86c, datum=0xefffcd80, nullv=0xefffcd20 " \230",
fInfo=0x0) at index.c:1284
#2 0x4a4e8 in CatalogIndexInsert (idescs=0xefffcdf8, nIndices=3,
heapRelation=0x171b90, heapTuple=0x1ba810)
at indexing.c:154
#3 0x4fb2c in ProcedureCreate (procedureName=0x166bf0 "widget_in", returnsSet=0
'\000',
returnTypeName=0x166bb0 "widget", languageName=0xefffcf98 "C",
prosrc=0xeb800 "-",
probin=0x1aeb10 "/usr/local/pgsql/src/test/regress/input/../regress.so",
canCache=112 'p',
trusted=1 '\001', byte_pct=100, perbyte_cpu=0, percall_cpu=0,
outin_ratio=100, argList=0x166bd0,
dest=Remote) at pg_proc.c:275
#4 0x55674 in CreateFunction (stmt=0x165a50, dest=Remote) at define.c:329
#5 0xb8430 in ProcessUtility (parsetree=0x165a50, dest=Remote) at utility.c:392
#6 0xb60f8 in pg_exec_query_dest (
query_string=0xefffd1a0 "CREATE FUNCTION widget_in(opaque)\n RETURNS
widget\n AS '/usr/local/pgsql/src/test/regress/input/../regress.so'\n
LANGUAGE 'c';", dest=Remote, aclOverride=0 '\000') at postgres.c:749
#7 0xb5fec in pg_exec_query (
query_string=0xefffd1a0 "CREATE FUNCTION widget_in(opaque)\n RETURNS
widget\n AS '/usr/local/pgsql/src/test/regress/input/../regress.so'\n
LANGUAGE 'c';") at postgres.c:687
#8 0xb72ec in PostgresMain (argc=10, argv=0xeffff268, real_argc=10,
real_argv=0xeffffd84) at postgres.c:1609
#9 0x9f27c in DoBackend (port=0x107c00) at postmaster.c:1519
#10 0x9ecf4 in BackendStartup (port=0x167c00) at postmaster.c:1291
#11 0x9e16c in ServerLoop () at postmaster.c:750
#12 0x9dcc4 in PostmasterMain (argc=0, argv=0xeffffd84) at postmaster.c:556
#13 0x723b0 in main (argc=10, argv=0xeffffd84) at main.c:93

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

Thomas A. Szybist <szybist@boxhill.com>

If I compile backend/catalog with -O2 then the table creation is

^^^

OK. So it looks like it may be indexing.c, even with Bruce's
recent fixes.

Do you mean -O0 here?

Yes, a typo, I used -O0 for this dir.

I managed to get this running on a Solaris box. -O2 was not included
by default (wonder why :)). I got a core dump when running initdb
with -O2. I recompiled indexing.c without -O2, and it is much better.
(I basically get the same results as under Linux.) I get the same
core dumps that Keith is seeing with create function.

So, both my Sparc boxes are behaving the same.

I've not got round to trying a build on my Solaris 2.6 box yet. I was
hoping that someone with something faster than a SPARC 2 would do
the biz and get the same results.

So we have at least two problems, some code that is tickling a gcc
optimiser bug (gcc 2.7.2.1 in my case) and an alignment bug in our
code that affects SPARC architecture.

I've half a mind to see if there is a later version of gcc that
does the optimisation correctly. (rpm format for Redhat 4.2)

The "create function" problem is a little harder for me to see
a way forward. ( my debugging skills are very few.)

Keith.

The "create function" problem is a little harder for me to see
a way forward. ( my debugging skills are very few.)

Hmm. Bruce's most recent patches didn't fix my problems on Linux/i686
reported earlier. So I figured I'd try a full build with -O0 just to see
if it helped. Not only did it not help, but I got several other
regression tests failing, some with core dumps which did not crash with
-O2. Weird.

- Tom

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

The old code in this section was somewhat mangled.

Can I telnet into this machine?

I'm afraid I'm dialup only but would be willing to liase with
you and be online for you to telnet in, if no alternative
permanently connected system can be found.

Program received signal SIGSEGV, Segmentation fault.
0x34264 in GetIndexValue (tuple=0x1ba810, hTupDesc=0x1ba86c, attOff=0,
attrNums=0x1bd544, fInfo=0x0,
attNull=0xefffcc97 "") at indexam.c:404
404 returnVal = heap_getattr(tuple, attrNums[attOff],
(gdb) bt
#0 0x34264 in GetIndexValue (tuple=0x1ba810, hTupDesc=0x1ba86c, attOff=0,
attrNums=0x1bd544, fInfo=0x0,

My guess is that hTupDesc is badly formed, not having the proper
attributes for the relation. Can you do a print of *hTupDesc, and
attrNums[0]?

Breakpoint 1, GetIndexValue (tuple=0x1bc210, hTupDesc=0x1bc26c, attOff=0,
attrNums=0x1bf944, fInfo=0x0,
attNull=0xefffcc97 "") at indexam.c:383
383 if (PointerIsValid(fInfo) && FIgetProcOid(fInfo) != InvalidOid)
(gdb) step
404 returnVal = heap_getattr(tuple, attrNums[attOff],
(gdb) list
399 pfree(attData);
400 *attNull = FALSE;
401 }
402 else
403 {
404 returnVal = heap_getattr(tuple, attrNums[attOff],
405
hTupDesc, attNull);
406 }
407 return returnVal;
408 }
(gdb) print tuple
$1 = (HeapTupleData *) 0x1bc210
(gdb) print *tuple
$2 = {t_len = 205, t_oid = 18241, t_cmin = 0, t_cmax = 0, t_xmin = 22018, t_xmax
= 0, t_ctid = {ip_blkid = {
bi_hi = 0, bi_lo = 18}, ip_posid = 31}, t_natts = 16, t_infomask = 2050,
t_hoff = 40 '(',
t_bits = "\000\000\000"}
(gdb) print attrNums[attOff]
$3 = 15

This is a very interesting number. It is saying that it is the prosrc
field index that it is updating. This never used to work because of a
bug in the code for this index. Let me look at this some more.

(gdb) print *hTupDesc
$5 = {natts = 0, attrs = 0x0, constr = 0x0}
(gdb) print fInfo
$6 = (FuncIndexInfo *) 0x0

Hope this helps,
Keith.

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

Thomas A. Szybist <szybist@boxhill.com>

If I compile backend/catalog with -O2 then the table creation is

^^^

OK. So it looks like it may be indexing.c, even with Bruce's
recent fixes.

Do you mean -O0 here?

Yes, a typo, I used -O0 for this dir.

Can you try:

select * from pg_index;

Crashes here. Not good.

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

The old code in this section was somewhat mangled.

Can I telnet into this machine?

I'm afraid I'm dialup only but would be willing to liase with
you and be online for you to telnet in, if no alternative
permanently connected system can be found.

Sorry. pg_index works now. My fault.

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

Thomas A. Szybist <szybist@boxhill.com>

If I compile backend/catalog with -O2 then the table creation is

^^^

OK. So it looks like it may be indexing.c, even with Bruce's
recent fixes.

Do you mean -O0 here?

Yes, a typo, I used -O0 for this dir.

One idea is to track heapDescriptor from CatalogIndexInsert() all the
way down into the lower functions.

Compile with assert checking, which I assume you are already doing.

Add this "Assert(heapDescriptor->natts != 0)" to the function, and in
lower functions substitute heapDescriptor with the new variable name it
took as a function parameter.)

When the assert fails, we can see where it is getting messed up.

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

Thomas A. Szybist <szybist@boxhill.com>

If I compile backend/catalog with -O2 then the table creation is

^^^

OK. So it looks like it may be indexing.c, even with Bruce's
recent fixes.

Do you mean -O0 here?

Yes, a typo, I used -O0 for this dir.

Can you try:

select * from pg_index;

Crashes here. Not good.

Looks OK here!!

template1=> select * from pg_index;
indexrelid|indrelid|indproc| indkey|
indclass|indisclustered|indislossy|indhaskeytype|indisunique|indpred
----------+--------+-------+----------------+----------------------+------------
--+----------+-------------+-----------+-------
17061| 1249| 0| 1 2 0 0 0 0 0 0| 427 1181 0 0 0 0 0 0|f
|f |t |f |
17064| 1249| 0| 1 6 0 0 0 0 0 0| 427 421 0 0 0 0 0 0|f
|f |t |f |
17067| 1249| 0| 1 0 0 0 0 0 0 0| 427 0 0 0 0 0 0 0|f
|f |t |f |
17070| 1255| 0|-2 0 0 0 0 0 0 0| 427 0 0 0 0 0 0 0|f
|f |t |f |
17073| 1255| 0|1 7 10 0 0 0 0 0|1181 421 435 0 0 0 0 0|f
|f |t |f |
17076| 1255| 0|15 0 0 0 0 0 0 0| 431 0 0 0 0 0 0 0|f
|f |t |f |
17079| 1247| 0|-2 0 0 0 0 0 0 0| 427 0 0 0 0 0 0 0|f
|f |t |f |
17082| 1247| 0| 1 0 0 0 0 0 0 0| 1181 0 0 0 0 0 0 0|f
|f |t |f |
17085| 1259| 0|-2 0 0 0 0 0 0 0| 427 0 0 0 0 0 0 0|f
|f |t |f |
17088| 1259| 0| 1 0 0 0 0 0 0 0| 1181 0 0 0 0 0 0 0|f
|f |t |f |
17091| 1215| 0| 1 0 0 0 0 0 0 0| 427 0 0 0 0 0 0 0|f
|f |t |f |
17094| 1216| 0| 1 0 0 0 0 0 0 0| 427 0 0 0 0 0 0 0|f
|f |t |f |
17097| 1219| 0| 1 0 0 0 0 0 0 0| 427 0 0 0 0 0 0 0|f
|f |t |f |
17100| 17051| 0| 1 0 0 0 0 0 0 0| 427 0 0 0 0 0 0 0|f
|f |t |f |
(14 rows)

template1=>

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

Thomas A. Szybist <szybist@boxhill.com>

If I compile backend/catalog with -O2 then the table creation is

^^^

OK. So it looks like it may be indexing.c, even with Bruce's
recent fixes.

Do you mean -O0 here?

Yes, a typo, I used -O0 for this dir.

One idea is to track heapDescriptor from CatalogIndexInsert() all the
way down into the lower functions.

Compile with assert checking, which I assume you are already doing.

I'm afraid I don't normally as I tend to take everything at it's default
and build/install without changes.

Add this "Assert(heapDescriptor->natts != 0)" to the function, and in
lower functions substitute heapDescriptor with the new variable name it
took as a function parameter.)

When the assert fails, we can see where it is getting messed up.

I'm on the late shift this week so won't be home until 22:00 BST but
will endeavour to do something with this later this evening.

Keith.

In message <199809010623.CAA00709@candle.pha.pa.us>, Bruce Momjian writes:

Thomas A. Szybist <szybist@boxhill.com>

If I compile backend/catalog with -O2 then the table creation is

^^^

OK. So it looks like it may be indexing.c, even with Bruce's
recent fixes.

Do you mean -O0 here?

Yes, a typo, I used -O0 for this dir.

One idea is to track heapDescriptor from CatalogIndexInsert() all the
way down into the lower functions.

Compile with assert checking, which I assume you are already doing.

Add this "Assert(heapDescriptor->natts != 0)" to the function, and in
lower functions substitute heapDescriptor with the new variable name it
took as a function parameter.)

When the assert fails, we can see where it is getting messed up.

-- 
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 don't know if this helps, but here's what I've done so far. I'm now on
a Solaris Box, since the optimization thing seems to be similar to the
Linux Box. Its just easier for me to work on the Solaris Box.

When indexing.c is compiled with -O2, I get a core dump. (Big news.)
The core dump occurs at line 208 of backend/access/common/heaptuple.c.
at this memmove.

{
data = (char *) LONGALIGN(data);
memmove(data, DatumGetPointer(value[i]),
att[i]->attlen);
data += att[i]->attlen;
}

This consistantly happens when tupleDesc->natts is 1. When i = 1 on the
second time on the outer loop, value[1] is something like 2123236.
This is out of range when it gets derefenced, memmove barfs.

I was backtracking and turning on debugging one file at a time, but got
lost in fmgr.c.

I'll insert the asserts like you suggested.

Bruce, I can let you on this machine if you like.

Thanks,

Tom

#0 0xef5d0580 in _memcpy ()
(gdb) bt
#0 0xef5d0580 in _memcpy ()
#1 0x297e0 in DataFill (data=0x1a8e0c "", tupleDesc=0x15dce8, value=0xefffccac,
nulls=0xefffccb0 "", infomask=0xefffc9c6, bit=0x1a8e00 "\003") at heaptuple.c:208
#2 0x2bf24 in index_formtuple (tupleDescriptor=0x15dce8, value=0xefffccac, null=0xefffccb0 "")
at indextuple.c:76
#3 0x3ff40 in btinsert (rel=0x1a8060, datum=0xefffccac, nulls=0xefffccb0 "", ht_ctid=0x1a8858,
heapRel=0x166a38) at nbtree.c:358
#4 0xde1bc in fmgr_c (finfo=0xefffcb70, values=0xefffcb80, isNull=0xefffcb6f "") at fmgr.c:115
#5 0xde7bc in fmgr (procedureId=331) at fmgr.c:286
#6 0x38c3c in index_insert ()
#7 0x4d440 in CatalogIndexInsert ()
#8 0x4a6c4 in AddNewAttributeTuples ()
#9 0x4a968 in heap_create_with_catalog ()
#10 0x51b70 in DefineRelation ()
#11 0xb7884 in ProcessUtility ()
#12 0xb5da8 in pg_exec_query_dest ()
#13 0xb5c9c in pg_exec_query ()
#14 0xb6eb8 in PostgresMain ()
#15 0x9ef90 in DoBackend ()
#16 0x9e9dc in BackendStartup ()
#17 0x9df64 in ServerLoop ()
#18 0x9dab8 in PostmasterMain ()
#19 0x722e4 in main ()

Thomas A. Szybist <szybist@boxhill.com>

If I compile backend/catalog with -O2 then the table creation is

^^^

OK. So it looks like it may be indexing.c, even with Bruce's
recent fixes.

Do you mean -O0 here?

Yes, a typo, I used -O0 for this dir.

Can we try a simple -O rather than just -O2 and -O0. Could this be some
type of optimizer bug in gcc2/Solaris?

Everything is pointing to indexing.c, from both the initdb failure and
the create function failure. But I can't see anything wrong in there,
and other platforms seem to be OK.

Someone mentioned that Solaris does not use -O2 by default, and there
may be a good reason for this.

The new code is more streamlined from the megapatch, and perhaps the
optimizer is now able to do too much optimizing.

I don't want to go casting blame other places, but I think gcc that may
be the cause, and if it is, we just need to lower the default
optimization for those platforms.

Let's try adding Assert checking with the configure --enable-cassert
option, and compiling with -O rather than -O2 and see what happens.

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

Can we try a simple -O rather than just -O2 and -O0. Could this be
some type of optimizer bug in gcc2/Solaris?
Everything is pointing to indexing.c, from both the initdb failure and
the create function failure. But I can't see anything wrong in there,
and other platforms seem to be OK.

Uh, no, Linux/i686 is showing trouble too, but not in the initdb stage.
The Sparc platforms will be more sensitive to byte alignment problems,
especially within C structures, so this may be illustrating a
cross-platform problem more clearly.

There is a repeatable indexing and (perhaps) caching problem I see in
the regression tests. Annoyingly, the problems get slightly worse at the
moment when compiling with -O0.

There is a fundamental problem lurking somewhere, and there may not be
much point in going beta unless you think that more testers will help to
track down the problem.

- Tom

Bruce Momjian wrote:

Thomas A. Szybist <szybist@boxhill.com>

If I compile backend/catalog with -O2 then the table creation is

^^^

OK. So it looks like it may be indexing.c, even with Bruce's
recent fixes.

Do you mean -O0 here?

Yes, a typo, I used -O0 for this dir.

Can we try a simple -O rather than just -O2 and -O0. Could this be some
type of optimizer bug in gcc2/Solaris?

Everything is pointing to indexing.c, from both the initdb failure and
the create function failure. But I can't see anything wrong in there,
and other platforms seem to be OK.

Bruce,

I do not know if this problem is related in any way, but I have a serious
problem on AIX 4.1. I am jumping in here because there is a chance they are
related. Just manifest differently.

If I add an index to a table I can no longer use the table. In essence,
the look up on relname in pg_class fails. If I:
SELECT * FROM pg_class WHERE relname = 'table_i_just_indexed'
-- or \d table_i_just_indexed
I get no results.
SELECT * FROM pg_class
Displays it perfectly. So does:
SELECT * FROM pg_class WHERE relname like '%table_i_just_indexed'
If I manually correct relname:
UPDATE pg_class SET relname = 'table_i_just_indexed' WHERE relname like
'%table_i_just_indexed'
Everything seems to function normally again.

I can not reproduce on my Linux box. Assertions show nothing. This can't be
good.

Andreas, are you having any success?

Can we try a simple -O rather than just -O2 and -O0. Could this be some
type of optimizer bug in gcc2/Solaris?

Everything is pointing to indexing.c, from both the initdb failure and
the create function failure. But I can't see anything wrong in there,
and other platforms seem to be OK.

Bruce,

I do not know if this problem is related in any way, but I have a serious
problem on AIX 4.1. I am jumping in here because there is a chance they are
related. Just manifest differently.

If I add an index to a table I can no longer use the table. In essence,
the look up on relname in pg_class fails. If I:
SELECT * FROM pg_class WHERE relname = 'table_i_just_indexed'
-- or \d table_i_just_indexed
I get no results.
SELECT * FROM pg_class
Displays it perfectly. So does:
SELECT * FROM pg_class WHERE relname like '%table_i_just_indexed'
If I manually correct relname:
UPDATE pg_class SET relname = 'table_i_just_indexed' WHERE relname like
'%table_i_just_indexed'
Everything seems to function normally again.

I can not reproduce on my Linux box. Assertions show nothing. This can't be
good.

Wow, this is terribly frustrating. All these problems, and I can't
reproduce any of them here.

I sure hope they all have one cause, and I hope we find the cause 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)

Can we try a simple -O rather than just -O2 and -O0. Could this be
some type of optimizer bug in gcc2/Solaris?
Everything is pointing to indexing.c, from both the initdb failure and
the create function failure. But I can't see anything wrong in there,
and other platforms seem to be OK.

Uh, no, Linux/i686 is showing trouble too, but not in the initdb stage.
The Sparc platforms will be more sensitive to byte alignment problems,
especially within C structures, so this may be illustrating a
cross-platform problem more clearly.

There is a repeatable indexing and (perhaps) caching problem I see in
the regression tests. Annoyingly, the problems get slightly worse at the
moment when compiling with -O0.

There is a fundamental problem lurking somewhere, and there may not be
much point in going beta unless you think that more testers will help to
track down the problem.

OK, let me send you my regression output, and perhaps you can see the
problem in there so I can debug it.

We have a configure problem too, that Tatsuo pointed out. I removed my
config.cache, and tried to run configure, and got this. I added 'set
-x' to help.

+ pwd
+ test -z /usr/ucb:/sbin:/usr/sbin:/bin:/usr/bin:/usr/contrib/bin:/usr/X11/bin:/usr/local/postgres/bin:/usr/local/bin:/usr/local/sbin:.:/usr/local/sbin:.:/usr/local/src/pgsql/pgsql/src
+ test -f /usr/ucb /sbin /usr/sbin /bin /usr/bin /usr/contrib/bin /usr/X11/bin /usr/local/postgres/bin /usr/local/bin /usr/local/sbin . /usr/local/sbin . /usr/local/src/pgsql/pgsql/src/install-sh
test: syntax error: Undefined error: 0
+ IFS= 

+ INSTALL=
+ test -n 
+ echo no
no
+ test -n 
+ test -n 
+ INSTALL=NONE
+ test NONE = NONE
+ echo - No Install Script found - aborting.
- No Install Script found - aborting.
+ exit 0

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

OK, let me send you my regression output, and perhaps you can see the
problem in there so I can debug it.

As far as the beta, I am totally confused about the problems we are
having, and I don't know what to suggest. Perhaps you can see the
problems in my regression output.

We have a configure problem too, that Tatsuo pointed out. I removed my
config.cache, and tried to run configure, and got this. I added 'set
-x' to help.

OK, I have fixed the configure problem. The path has to have
directories separated by space, not colons. Works 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)

Can we try a simple -O rather than just -O2 and -O0. Could this be
some type of optimizer bug in gcc2/Solaris?
Everything is pointing to indexing.c, from both the initdb failure and
the create function failure. But I can't see anything wrong in there,
and other platforms seem to be OK.

Uh, no, Linux/i686 is showing trouble too, but not in the initdb stage.
The Sparc platforms will be more sensitive to byte alignment problems,
especially within C structures, so this may be illustrating a
cross-platform problem more clearly.

There is a repeatable indexing and (perhaps) caching problem I see in
the regression tests. Annoyingly, the problems get slightly worse at the
moment when compiling with -O0.

OK, here is my regression output. Do you see anything strange in there?

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

Uh, no, Linux/i686 is showing trouble too, but not in the initdb
stage. The Sparc platforms will be more sensitive to byte alignment
problems, especially within C structures, so this may be
illustrating a cross-platform problem more clearly.
There is a repeatable indexing and (perhaps) caching problem I see
in the regression tests. Annoyingly, the problems get slightly worse
at the moment when compiling with -O0.

OK, here is my regression output. Do you see anything strange in
there?

Well, yes, just not as strange as my tests :) You don't have int8
enabled, and if your compiler and libc allow it I'd like to get that
going. But that isn't a problem.

You have a core dump from the "having" test. Is that a known problem
with someone working on a solution? The test worked on my ~month-old
development tree (I could probably figure out the vintage of that tree
to more precision if it would be helpful), so something has happened in
the meantime.

I suspect that (possibly) more than one thing is going on, since there
were some changes directly related to removing the oddball OID types as
well as perhaps cleanup changes made while traversing the code.
Something may have crept in there.

If these tests are the only ones showing problems on your machine, then
consider yourself lucky. I've got several more failures, including the
one where I can't create indices on a table until after terminating and
restarting the session. The Sparc contingent sees more problems than I,
but they are on a Risc machine so will see alignment problems if they
are present.

- Tom

======   int8   ======
--- expected/int8.out   Sun Aug 23 11:09:38 1998
+++ results/int8.out    Tue Sep  1 23:40:10 1998
@@ -6,110 +6,110 @@
QUERY: INSERT INTO INT8_TBL VALUES('4567890123456789','-4567890123456789');
QUERY: SELECT * FROM INT8_TBL;
q1|               q2
-----------------+-----------------
+----------+-----------
123|              456
-             123| 4567890123456789
-4567890123456789|              123
-4567890123456789| 4567890123456789
-4567890123456789|-4567890123456789
+       123| 2147483647
+2147483647|        123
+2147483647| 2147483647
+2147483647|-2147483648
(5 rows)
======   select_having   ======
--- expected/select_having.out  Sat Aug 29 00:10:03 1998
+++ results/select_having.out   Tue Sep  1 23:41:51 1998
@@ -11,27 +11,6 @@
QUERY: INSERT INTO test_having VALUES (9, 4, 'CCCC', 'j');
QUERY: SELECT max(a) FROM test_having
GROUP BY lower(c) HAVING count(*) > 2 OR min(b) = 3;

<snip>

-QUERY: DROP TABLE test_having;
+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.

OK, this test did not fail on my development tree from a month ago. What
changed? I'm seeing it fail here also.

- Tom

I can not reproduce on my Linux box. Assertions show nothing. This can't be
good.
Andreas, are you having any success?

The goodies:
using %lld for int8 I get
int8 .. ok
create_function_2 .. ok
select_having .. ok

The down side:
create_index .. failed

Same problem here:
after one create index the pg_class_relname_index is no good any more I get

regression=> CREATE INDEX onek_unique2 ON onek USING btree(unique2 int4_ops);
CREATE
regression=> select * from onek;
ERROR: RelationCatalogInformation: Relation 19284 not found
regression=> \q
postgres@zeus:/usr/postgres/src/test/regress> psql regression
regression=> select * from onek;
ERROR: onek: Table does not exist.
regression=>

one problem with #ifdef 0, please use #ifdef NOT_USED in
src/backend/utils/misc/database.c

Andreas

Uh, no, Linux/i686 is showing trouble too, but not in the initdb
stage. The Sparc platforms will be more sensitive to byte alignment
problems, especially within C structures, so this may be
illustrating a cross-platform problem more clearly.
There is a repeatable indexing and (perhaps) caching problem I see
in the regression tests. Annoyingly, the problems get slightly worse
at the moment when compiling with -O0.

OK, here is my regression output. Do you see anything strange in
there?

Well, yes, just not as strange as my tests :) You don't have int8
enabled, and if your compiler and libc allow it I'd like to get that
going. But that isn't a problem.

You have a core dump from the "having" test. Is that a known problem
with someone working on a solution? The test worked on my ~month-old
development tree (I could probably figure out the vintage of that tree
to more precision if it would be helpful), so something has happened in
the meantime.

I suspect that (possibly) more than one thing is going on, since there
were some changes directly related to removing the oddball OID types as
well as perhaps cleanup changes made while traversing the code.
Something may have crept in there.

If these tests are the only ones showing problems on your machine, then
consider yourself lucky. I've got several more failures, including the
one where I can't create indices on a table until after terminating and
restarting the session. The Sparc contingent sees more problems than I,
but they are on a Risc machine so will see alignment problems if they
are present.

Yes, very strange.

- Tom

======   int8   ======
--- expected/int8.out   Sun Aug 23 11:09:38 1998
+++ results/int8.out    Tue Sep  1 23:40:10 1998
@@ -6,110 +6,110 @@
QUERY: INSERT INTO INT8_TBL VALUES('4567890123456789','-4567890123456789');
QUERY: SELECT * FROM INT8_TBL;
q1|               q2
-----------------+-----------------
+----------+-----------
123|              456
-             123| 4567890123456789
-4567890123456789|              123
-4567890123456789| 4567890123456789
-4567890123456789|-4567890123456789
+       123| 2147483647
+2147483647|        123
+2147483647| 2147483647
+2147483647|-2147483648
(5 rows)
======   select_having   ======
--- expected/select_having.out  Sat Aug 29 00:10:03 1998
+++ results/select_having.out   Tue Sep  1 23:41:51 1998
@@ -11,27 +11,6 @@
QUERY: INSERT INTO test_having VALUES (9, 4, 'CCCC', 'j');
QUERY: SELECT max(a) FROM test_having
GROUP BY lower(c) HAVING count(*) > 2 OR min(b) = 3;

<snip>

-QUERY: DROP TABLE test_having;
+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.

OK, this test did not fail on my development tree from a month ago. What
changed? I'm seeing it fail here also.

I believe David Hartwig has claimed this problem, and knows the cause.
He posted something recently.

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

Can we try a simple -O rather than just -O2 and -O0. Could this be
some type of optimizer bug in gcc2/Solaris?
Everything is pointing to indexing.c, from both the initdb failure and
the create function failure. But I can't see anything wrong in there,
and other platforms seem to be OK.

Uh, no, Linux/i686 is showing trouble too, but not in the initdb stage.
The Sparc platforms will be more sensitive to byte alignment problems,
especially within C structures, so this may be illustrating a
cross-platform problem more clearly.

There is a repeatable indexing and (perhaps) caching problem I see in
the regression tests. Annoyingly, the problems get slightly worse at the
moment when compiling with -O0.

Can you see if compiling indexing.c with different optmization levels
change the output? If so, would someone else also look in indexing.c
for somethings stupid I did. I can't see it, but EVERYTHING is
pointing to that file.

There is a fundamental problem lurking somewhere, and there may not be
much point in going beta unless you think that more testers will help to
track down the problem.

Not sure how to find the problem. Without being able to debug it here,
I am left staring at the code over and over again.

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

Not sure how to find the problem. Without being able to debug it here,
I am left staring at the code over and over again.

That sounds like *so* much fun ;-)

OK, I've been ignoring the problem until now, and of course may not be
of any help even if I were trying to help. I'm also not quite up on the
history and sequence of events which led to our current state, and I'm
not sure we have a strong regression history yet to pin this down.

At the moment we have Bruce and the two sparc guys working on it, and
Bruce can't reproduce the problems on his machine and Keith's machine is
so dog-slow that he can't do much testing which involve full rebuilds.
Boy, it hasn't been long since that model Sparc was the best thing
going, eh?

Does anyone else have a machine (Linux x86, for example) which exhibits
problems with the current development tree, and who has an interest in
helping to track this down?

I hate to step away from docs, but could for a while if that would be
helpful. I've got a fairly fast machine and can try pinning down when
the problems started by doing full builds on fresh trees. Or since we've
been making steady incremental improvements to the tree, maybe we should
focus on a particular problem; my "can't create another index in the
current session" problem is probably related to whatever else is going
on with indices.

In general the problems persist across different "-O" compiler settings
and across different architectures and compilers, though with different
symptoms, so I would think that this is not a compiler bug per se.

- Tom

Bruce Momjian wrote:

Not sure how to find the problem. Without being able to debug it here,
I am left staring at the code over and over again.

That sounds like *so* much fun ;-)

OK, I've been ignoring the problem until now, and of course may not be
of any help even if I were trying to help. I'm also not quite up on the
history and sequence of events which led to our current state, and I'm
not sure we have a strong regression history yet to pin this down.

At the moment we have Bruce and the two sparc guys working on it, and
Bruce can't reproduce the problems on his machine and Keith's machine is
so dog-slow that he can't do much testing which involve full rebuilds.
Boy, it hasn't been long since that model Sparc was the best thing
going, eh?

I was on Thomas A. Szybist machine for two hours, and even though I was
telnet'ed across three Internet machines to get there, it made my PP200
look like it was sitting still. Amazing speed. It is a Sparc running
Solaris.

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

Thomas G. Lockhart wrote:

Uh, no, Linux/i686 is showing trouble too, but not in the initdb
stage. The Sparc platforms will be more sensitive to byte alignment
problems, especially within C structures, so this may be
illustrating a cross-platform problem more clearly.
There is a repeatable indexing and (perhaps) caching problem I see
in the regression tests. Annoyingly, the problems get slightly worse
at the moment when compiling with -O0.

OK, here is my regression output. Do you see anything strange in
there?

Well, yes, just not as strange as my tests :) You don't have int8
enabled, and if your compiler and libc allow it I'd like to get that
going. But that isn't a problem.

You have a core dump from the "having" test. Is that a known problem
with someone working on a solution? The test worked on my ~month-old
development tree (I could probably figure out the vintage of that tree
to more precision if it would be helpful), so something has happened in
the meantime.

I submitted two patch patches to fix the select_having test. The first patch addressed problems caused by
a machine dependency on the degree of accuracy of datetime. CVS is currently showing this first patch.

The second patch was to fix my first patch. It has NOT been applied yet. The problem with he first
patch, which you are seeing now, is that the test case demonstrates another bug which has nothing to do
with having. It has to do with GROUPing by a function and the argument of the function not appearing
elsewhere in the target list. Weird! In any case the latest patch will fix the regression.

BTW, I have also sent one other patch that I am waiting to see in CVS. These one is an interim AND/OR
memory exhaustion fix.

Andreas Zeugswetter wrote:

regression=> CREATE INDEX onek_unique2 ON onek USING btree(unique2 int4_ops);
CREATE
regression=> select * from onek;
ERROR: RelationCatalogInformation: Relation 19284 not found
regression=> \q
postgres@zeus:/usr/postgres/src/test/regress> psql regression
regression=> select * from onek;
ERROR: onek: Table does not exist.

That's the one. See my earlier posting about the state of the pg_class tuple.

In message <199809021542.LAA02771@candle.pha.pa.us>, Bruce Momjian writes:

Bruce Momjian wrote:

Not sure how to find the problem. Without being able to debug it here,
I am left staring at the code over and over again.

That sounds like *so* much fun ;-)

OK, I've been ignoring the problem until now, and of course may not be
of any help even if I were trying to help. I'm also not quite up on the
history and sequence of events which led to our current state, and I'm
not sure we have a strong regression history yet to pin this down.

At the moment we have Bruce and the two sparc guys working on it, and
Bruce can't reproduce the problems on his machine and Keith's machine is
so dog-slow that he can't do much testing which involve full rebuilds.
Boy, it hasn't been long since that model Sparc was the best thing
going, eh?

I was on Thomas A. Szybist machine for two hours, and even though I was

^^^^^^^^^^^^^^^^^
It's really just Tom :)

telnet'ed across three Internet machines to get there, it made my PP200
look like it was sitting still. Amazing speed. It is a Sparc running
Solaris.

-- 
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 just grabbed grabbed gcc 2.8.1 from smc.vnet.com. I should have that
installed later today. Full rebuilds are not a problem for me. I did
just get a project bubbled to the top of my queue here that should take
about a day or two. I certainly can try patches and such, but I may
not have time plod through with gdb for a few days. (Not that I can
help much anyway.) I'm also going to be away for Labor day starting
Friday night EST. I'm returning on Tuesday night EST.

Tom Szybist
szybist@boxhill.com

I submitted two patch patches to fix the select_having test. The first patch addressed problems caused by
a machine dependency on the degree of accuracy of datetime. CVS is currently showing this first patch.

The second patch was to fix my first patch. It has NOT been applied yet. The problem with he first
patch, which you are seeing now, is that the test case demonstrates another bug which has nothing to do
with having. It has to do with GROUPing by a function and the argument of the function not appearing
elsewhere in the target list. Weird! In any case the latest patch will fix the regression.

BTW, I have also sent one other patch that I am waiting to see in CVS. These one is an interim AND/OR
memory exhaustion fix.

Yes, I am behind on the patch applications. Marc probably stopped while
I did my mega-cleanup, and I have been scratching my head on the
platform failures. Hopefully one of us will get it 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)

Bruce Momjian wrote:

I submitted two patch patches to fix the select_having test. The first patch addressed problems caused by
a machine dependency on the degree of accuracy of datetime. CVS is currently showing this first patch.

The second patch was to fix my first patch. It has NOT been applied yet. The problem with he first
patch, which you are seeing now, is that the test case demonstrates another bug which has nothing to do
with having. It has to do with GROUPing by a function and the argument of the function not appearing
elsewhere in the target list. Weird! In any case the latest patch will fix the regression.

BTW, I have also sent one other patch that I am waiting to see in CVS. These one is an interim AND/OR
memory exhaustion fix.

Yes, I am behind on the patch applications. Marc probably stopped while
I did my mega-cleanup, and I have been scratching my head on the
platform failures. Hopefully one of us will get it soon.
bug.

No rush, I can see you're synapses are all firing on this index bug. Just a reminder so it doesn't fall
through the cracks.

More important, am relieved (in advance) that you have found the problem in the index code.

Can I assume there will be a snapshot I can get tomorrow from my business location to try out on my AIX box? I
am anxious to know this is behind us.

Appreciation :)

Thomas G. Lockhart <lockhart@alumni.caltech.edu>

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

Can we try a simple -O rather than just -O2 and -O0. Could this be
some type of optimizer bug in gcc2/Solaris?
Everything is pointing to indexing.c, from both the initdb failure and
the create function failure. But I can't see anything wrong in there,
and other platforms seem to be OK.

Compiled with -O the results are the same as with -O2. (-O is the same as -O1)

According to the gcc man -O0 turns off all optimisation.

Uh, no, Linux/i686 is showing trouble too, but not in the initdb stage.
The Sparc platforms will be more sensitive to byte alignment problems,
especially within C structures, so this may be illustrating a
cross-platform problem more clearly.

There is a repeatable indexing and (perhaps) caching problem I see in
the regression tests. Annoyingly, the problems get slightly worse at the
moment when compiling with -O0.

There is a fundamental problem lurking somewhere, and there may not be
much point in going beta unless you think that more testers will help to
track down the problem.

It's unfortunate that the person who has the best chance of tracking
down the bug(s), Bruce, is not seeing any of the problems :-(

I'm afraid I'm not going to be much help this week as the shift
I'm on leaves me little time to play with the workstation at home.

I'll be able to do test compiles but not much debugging.

Keith.

There is a fundamental problem lurking somewhere, and there may not be
much point in going beta unless you think that more testers will help to
track down the problem.

It's unfortunate that the person who has the best chance of tracking
down the bug(s), Bruce, is not seeing any of the problems :-(

I'm afraid I'm not going to be much help this week as the shift
I'm on leaves me little time to play with the workstation at home.

I'll be able to do test compiles but not much debugging.

We may have to call in the big guns(Vadim), but if I am not seeing the
problem, he may not either on FreeBSD.

At this point, the only thing we can point at is optimization of
indexing.c.

-- 
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 I have the FIX. HOLD ON.

Thomas G. Lockhart <lockhart@alumni.caltech.edu>

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

Can we try a simple -O rather than just -O2 and -O0. Could this be
some type of optimizer bug in gcc2/Solaris?
Everything is pointing to indexing.c, from both the initdb failure and
the create function failure. But I can't see anything wrong in there,
and other platforms seem to be OK.

Compiled with -O the results are the same as with -O2. (-O is the same as -O1)

According to the gcc man -O0 turns off all optimisation.

Uh, no, Linux/i686 is showing trouble too, but not in the initdb stage.
The Sparc platforms will be more sensitive to byte alignment problems,
especially within C structures, so this may be illustrating a
cross-platform problem more clearly.

There is a repeatable indexing and (perhaps) caching problem I see in
the regression tests. Annoyingly, the problems get slightly worse at the
moment when compiling with -O0.

There is a fundamental problem lurking somewhere, and there may not be
much point in going beta unless you think that more testers will help to
track down the problem.

It's unfortunate that the person who has the best chance of tracking
down the bug(s), Bruce, is not seeing any of the problems :-(

I'm afraid I'm not going to be much help this week as the shift
I'm on leaves me little time to play with the workstation at home.

I'll be able to do test compiles but not much debugging.

Keith.

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

No rush, I can see you're synapses are all firing on this index bug. Just a reminder so it doesn't fall
through the cracks.

Doing it now.

More important, am relieved (in advance) that you have found the problem in the index code.

Can I assume there will be a snapshot I can get tomorrow from my business location to try out on my AIX box? I
am anxious to know this is behind us.

Appreciation :)

Last I heard on Monday, Marc is making snapshots every day now, and
through the beta period.

Thanks to all the bug reports and tracebacks. They clearly pointed to
the problem. I just couldn't see it until today.

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

one problem with #ifdef 0, please use #ifdef NOT_USED in
src/backend/utils/misc/database.c

Andreas

Fixed.

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

At this point, the only thing we can point at is optimization of
indexing.c.

Maybe alignment from an underlying problem, but -O0 gives me problems
too on Linux/i686. I'll try ramping up in the next day or so to look at
my specific indexing symptom. Will be asking for help then...

- Tom

At this point, the only thing we can point at is optimization of
indexing.c.

Maybe alignment from an underlying problem, but -O0 gives me problems
too on Linux/i686. I'll try ramping up in the next day or so to look at
my specific indexing symptom. Will be asking for help then...

- Tom

Fixed. cvsup and let me know.

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