Sorry about the length of this one, but I wanted to include backtrace
info.  I've been getting a segfault when I try to setup a test version
of the current CVS tree, to run along beside a 'production' 6.5.X server.

This is how I've configured it:

wallace$./configure --prefix=/usr/local/pgsql7.0/ --with-pgport=6666 --enable-debug

After which make; make install works fine.

On my machine at home, where I can let pgsql take the default location
and port, I've had no trouble. With this one, at work, I get a segfault
when initdb tries to execute postgres in bootstrap mode. I've managed
to run postgres under gdb and capture a backtrace:

wallace$ which initdb
/usr/local/pgsql7.0/bin/initdb
wallace$ export | grep -i PG
declare -x LD_LIBRARY_PATH="/usr/local/pgsql7.0/lib"
declare -x PGDATA="/usr/local/pgsql7.0/data"
declare -x PGLIB="/usr/local/pgsql7.0/lib"
declare -x PWD="/extra/src/pgsql-current/src"
{PATH deleted}

{already ran initdb -d -n, then, after it failed, deleted
${PGDATA}/pg_control, and created an already sed processed version of
the template (just subs for PGUID) }

wallace$ gdb postgres  
GNU gdb 19990928
<deleted banner>
This GDB was configured as "i686-pc-linux-gnu"...
(gdb) set args -boot -x -C -F -D/usr/local/pgsql7.0/data -d template1 </home/reedstrm/template1.sql
(gdb) run
Starting program: /usr/local/pgsql7.0/bin/postgres -boot -x -C -F -D/usr/local/pgsql7.0/data -d template1 </home/reedstrm/template1.sql
<proname name> 
<proowner int4> 
<prolang oid> 
<proisinh bool> 
<proistrusted bool> 
<proiscachable bool> 
<pronargs int2> 
<proretset bool> 
<prorettype oid> 
<proargtypes oidvector> 
<probyte_pct int4> 
<properbyte_cpu int4> 
<propercall_cpu int4> 
<prooutin_ratio int4> 
<prosrc text> 
<probin bytea> 

> creating bootstrap relation

Program received signal SIGSEGV, Segmentation fault.
0x80eb266 in filepath (filename=0x81b2260 "pg_proc") at fd.c:529

529                     len = strlen(DatabasePath) + strlen(filename) + 2;
(gdb) bt
#0  0x80eb26
#1  0x80eb456 in FileNameOpenFile (fileName=0x81b2260 "pg_proc", fileFlags=194, fileMode=384)
    at fd.c:657
#2  0x80f1d44 in mdcreate (reln=0x81b18b0) at md.c:128
#3  0x80f2da7 in smgrcreate (which=0, reln=0x81b18b0) at smgr.c:134
#4  0x8081a9d in heap_storage_create (rel=0x81b18b0) at heap.c:352
#5  0x8081a4c in heap_create (relname=0x81b8d48 "pg_proc", tupDesc=0x81bdd28, isnoname=0 '\000', 
    istemp=0, storage_create=1 '\001') at heap.c:329
#6  0x807e95c in Int_yyparse () at bootparse.y:168
#7  0x8080557 in BootstrapMain (argc=7, argv=0xbffffc38) at bootstrap.c:395
#8  0x80afcee in main (argc=8, argv=0xbffffc34) at main.c:100

{grovel around in fd.c: looks like DatabasePath should be set by
SetDatabasePath, which uses ExpandDatabasePath to the value of DataDir +
dbName (template1) but somehow we missed it}

(gdb) print DatabasePath
$1 = 0x0
(gdb) print DataDir     
$2 = 0xbffffd97 "/usr/local/pgsql7.0/data"
(gdb) exit

Anyone have any ideas? I can recreate at will.

Ross
-- 
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu> 
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St.,  Houston, TX 77005

Mon, 6 Mar 2000 18:37:22 -0600
"Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
sqgfault on initdb with current CVS
> Sorry about the length of this one, but I wanted to include backtrace
> info.  I've been getting a segfault when I try to setup a test version
> of the current CVS tree, to run along beside a 'production' 6.5.X server.
> 
> This is how I've configured it:
> 
> wallace$./configure --prefix=/usr/local/pgsql7.0/ --with-pgport=6666 --enable-debug

For some reason, current does not seem to allow "." in the
$PGDATA. I'm no sure why this happens at all. I guess it intends to
inhibit "./" or "../" for a security reason? If so, that would be
apparently an overkill.
--
Tatsuo Ishii

Tue, 07 Mar 2000 10:07:16 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
Re: [HACKERS] sqgfault on initdb with current CVS
On Tue, Mar 07, 2000 at 10:07:16AM +0900, Tatsuo Ishii wrote:
> > Sorry about the length of this one, but I wanted to include backtrace
> > info.  I've been getting a segfault when I try to setup a test version
> > of the current CVS tree, to run along beside a 'production' 6.5.X server.
> > 
> > This is how I've configured it:
> > 
> > wallace$./configure --prefix=/usr/local/pgsql7.0/ --with-pgport=6666 --enable-debug
> 
> For some reason, current does not seem to allow "." in the
> $PGDATA. I'm no sure why this happens at all. I guess it intends to
> inhibit "./" or "../" for a security reason? If so, that would be
> apparently an overkill.

Thank you very much, Ishii-san, changing it to pgsql70 worked! If your ever in Houston,
I owe you a beer!

Ross
-- 
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu> 
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St.,  Houston, TX 77005

Mon, 6 Mar 2000 23:04:43 -0600
"Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
Re: [HACKERS] sqgfault on initdb with current CVS
> > wallace$./configure --prefix=/usr/local/pgsql7.0/ --with-pgport=6666 --enable-debug
> For some reason, current does not seem to allow "." in the
> $PGDATA. I'm no sure why this happens at all. I guess it intends to
> inhibit "./" or "../" for a security reason? If so, that would be
> apparently an overkill.

Bruce, can you add this item to the "must fix" list for the 7.0
release (hint hint - is it time to start that list?? ;)

Also, please add to the same list:

o implement the OVERLAPS date/time operator from SQL92 (Thomas)
o support TIME WITH TIME ZONE timezones in literals (Thomas)
o add support for full POSIX time zone specification (Thomas)

The POSIX time zone stuff is already in there, new for this release,
but needs to be polished to work with TZs away from GMT. The OVERLAPS
stuff is coded and being tested now; it just adds a few functions and
a bit of gram.y syntax.

                       - Thomas

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California

Tue, 07 Mar 2000 05:16:07 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: [HACKERS] sqgfault on initdb with current CVS
> > > wallace$./configure --prefix=/usr/local/pgsql7.0/ --with-pgport=6666 --enable-debug
> > For some reason, current does not seem to allow "." in the
> > $PGDATA. I'm no sure why this happens at all. I guess it intends to
> > inhibit "./" or "../" for a security reason? If so, that would be
> > apparently an overkill.
> 
> Bruce, can you add this item to the "must fix" list for the 7.0
> release (hint hint - is it time to start that list?? ;)

> 
> Also, please add to the same list:
> 
> o implement the OVERLAPS date/time operator from SQL92 (Thomas)
> o support TIME WITH TIME ZONE timezones in literals (Thomas)
> o add support for full POSIX time zone specification (Thomas)
> 


We don't have any must fixes for 7.0 yet.  Why are these worthy?

> The POSIX time zone stuff is already in there, new for this release,
> but needs to be polished to work with TZs away from GMT. The OVERLAPS
> stuff is coded and being tested now; it just adds a few functions and
> a bit of gram.y syntax.

Initdb required.  You better get an OK from Marc.


-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Tue, 7 Mar 2000 19:09:21 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] sqgfault on initdb with current CVS
On Tue, 7 Mar 2000, Bruce Momjian wrote:

> > > > wallace$./configure --prefix=/usr/local/pgsql7.0/ --with-pgport=6666 --enable-debug
> > > For some reason, current does not seem to allow "." in the
> > > $PGDATA. I'm no sure why this happens at all. I guess it intends to
> > > inhibit "./" or "../" for a security reason? If so, that would be
> > > apparently an overkill.
> > 
> > Bruce, can you add this item to the "must fix" list for the 7.0
> > release (hint hint - is it time to start that list?? ;)
> 
> > 
> > Also, please add to the same list:
> > 
> > o implement the OVERLAPS date/time operator from SQL92 (Thomas)
> > o support TIME WITH TIME ZONE timezones in literals (Thomas)
> > o add support for full POSIX time zone specification (Thomas)
> > 
> 
> 
> We don't have any must fixes for 7.0 yet.  Why are these worthy?
> 
> > The POSIX time zone stuff is already in there, new for this release,
> > but needs to be polished to work with TZs away from GMT. The OVERLAPS
> > stuff is coded and being tested now; it just adds a few functions and
> > a bit of gram.y syntax.
> 
> Initdb required.  You better get an OK from Marc.

Go for it ... no INITDBs after our first release candidate, but if these
are must-have's, we've only done one Beta1, so get it into Beta2...


Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 


Tue, 7 Mar 2000 21:08:27 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] sqgfault on initdb with current CVS