* Andrew Klosterman (andrew5@ece.cmu.edu) wrote:
> > Seems kind of unlikely... What exact (.deb) versions of libpq and
> > Postgres are you using? You originally posted w/ 8.1.0 but perhaps on
> > the client you had something more recent?
>=20
> Running "aptitude show X" where "X" is the package name, and applying
> appropriate filtering gives the following results on my development
> systems:
>=20
> Package: libpq-dev
> Version: 8.1.0-3
>=20
> Package: libpq3
> Version: 1:7.4.9-2
>=20
> Package: libpq4
> Version: 8.1.0-3
>=20
> Package: postgresql-8.1
> Version: 8.1.0-3
>=20
> Package: postgresql-contrib-8.1
> Version: 8.1.0-3
>=20
> Package: postgresql-server-dev-8.1
> Version: 8.1.0-3
>=20
> Package: postgresql-client-8.1
> Version: 8.1.0-3
>=20
> Package: postgresql-common
> Version: 39
Hmm, alright, well, this is at least not the fault of the patch of mine
which was included in Debian's 8.1.2-2 Postgres release. :) You might
try compiling some debs with debugging enabled. This is (reasonably)
straight-forward:
(as root:)
aptitude install build-essential debhelper cdbs bison perl libperl-dev \
tk8.4-dev flex libreadline5-dev libssl-dev zlib1g-dev \
libpam0g-dev libxml2-dev libkrb5-dev libxslt1-dev python-dev \
gettext bzip2 fakeroot
(as user:)
apt-get source postgresql-8.1
cd postgresql-8.1-8.1.0
export DEB_BUILD_OPTIONS=3D"nostrip"
dpkg-buildpackage -uc -us -rfakeroot
Should produce .debs in the parent directory which have debugging
information. Another useful build option is "noopt", ie:
export DEB_BUILD_OPTIONS=3D"nostrip noopt", though that could make the
error go disappear. It'd be terribly nice if you could do this and
provide a gdb backtrace with debugging... :)
Thanks,
Stephen