I did build postgres myself using the simple installation instructions
provided on the website
configure
gmake
gmake install
I'm a linux newbie so most of the stuff you mention, I don't know how to do.
I believe that psql is dumping because postmaster still runs after the
segmentation fault. Same goes for createdb. After I sent this note, I
downloaded 7.2.4 and did the same install as I did for 7.3.2 and everything
worked fine. How do I do a stack trace?
Patrick Bye
Programmer / Analyst
Westfair Foods Ltd.
pbye@westfair.ca
(403) 291-6538
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Wednesday, February 12, 2003 9:07 PM
To: Patrick Bye (WFF)
Cc: 'pgsql-general@postgresql.org'
Subject: Re: [GENERAL] Help with Segmentation Fault
"Patrick Bye (WFF)" <PBYE@Westfair.CA> writes:
> I just tried to upgrade to the lastest 7.3.2. I did a dumpall on my
> database and wiped out both my binary and data directories so I could
start
> the install from scratch. The configure, make and make install work fine.
> No errors reported from initdb and postmaster starts no problem. As soon
as
> I try to connect to template1 to restore my dumpall, I get a segmentation
> fault. If I try to do a createdb, I also get a segmentation fault.
You have not provided a whole lot of detail here, but reading between
the lines I guess that it is psql core-dumping, not the backend?
Most likely that would be a problem of incompatibility with one of the
shared libraries that psql depends on. It's difficult to say more than
that with no details though. Did you build 7.3.2 yourself (if so, with
what configure switches) or install an RPM (if so, whose)? Can you
provide a stack trace from the segfault core dump? Does ldd on the psql
executable report a sane-looking set of shlib dependencies?
regards, tom lane
