Hrm.
I did see the Fedora stashed copies of libpq.so.5 and libpq.so.5.2 in
/usr/lib64. I looked everywhere on the system for libpq.so*, and saw that the
only remaining copies where those in my source directory... so I re-built
9.0.3. A 'make check' still died in the same place within the regression
tests. I did a 'make install' anyhow. I cleaned out my data directory and
attempted a new initdb with 9.0.3. That seg faulted as well:
[postgres@infinity local]$ /usr/local/pgsql/bin/initdb -D /data/postgres
Segmentation fault (core dumped)
Any other suggestions?
- Matt
Quoting Craig Ringer <craig@postnewspapers.com.au>:
> On 03/02/11 09:53, Matt Zinicola wrote:
> > Apologies for lack of detail. Although I've been using Postgres for
> > years, this is the first time I've had such an issue.
> >
> > Build options were only --with-perl and --with-python
> >
> > Below is the output when two different applications attempt to connect
> > to my 9.0.3 server (note, the second is psql itself):
> >
> > [root@infinity postgres]# /etc/init.d/archiveopteryx start
> > Starting Archiveopteryx: aox: Couldn't connect to PostgreSQL. (on
> > backend 1)
> > /etc/init.d/archiveopteryx: line 24: 4240 Segmentation
> > fault /usr/local/archiveopteryx/bin/aox start
> > done.
> >
> > [postgres@infinity scripts]$ psql template1
> > Segmentation fault (core dumped)
>
> OK, so it's not the PostgreSQL backend that's crashing, it's psql.
>
> You almost certainly have conflicting libraries lurking around
> somewhere, so psql was built against one libpq but lands up getting
> linked to another at runtime.
>
> --
> System & Network Administrator
> POST Newspapers
>
