psql 9.1 alpha5: connection pointer is NULL
I'm getting the following message after upgrading to Alpha5 on my Fedora
14 box:
$ psql -p 5433
psql: connection pointer is NULL
which comes from libpq. Server is running, and I can connect it to via
9.0's psql.
This is a regular RPM build. Am I doing something wrong, or?
Regards,
--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
2011/4/2 Devrim GÜNDÜZ <devrim@gunduz.org>:
I'm getting the following message after upgrading to Alpha5 on my Fedora
14 box:$ psql -p 5433
psql: connection pointer is NULLwhich comes from libpq. Server is running, and I can connect it to via
9.0's psql.This is a regular RPM build. Am I doing something wrong, or?
I couldn't reproduce this (using upstream source on Ubuntu). However,
I did find a little bug in libpq causing the connection handle to
become NULL in the event of an option parsing error. This bug has
been around since release 9.0.0, and may be unrelated to the problem.
Joey Adams
Attachments:
PQconnectStartParams-fix-return-false.patchtext/x-patch; charset=US-ASCII; name=PQconnectStartParams-fix-return-false.patchDownload
From 5bcf99b6481dd1393525ee804eeae6a04999d86d Mon Sep 17 00:00:00 2001
From: Joey Adams <joeyadams3.14159@gmail.com>
Date: Sat, 2 Apr 2011 14:27:22 -0400
Subject: [PATCH] Fixed "return false;" in PQconnectStartParams, which returns a PGconn *
---
src/interfaces/libpq/fe-connect.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/interfaces/libpq/fe-connect.c b/src/interfaces/libpq/fe-connect.c
index a4959ee..aa24c37 100644
--- a/src/interfaces/libpq/fe-connect.c
+++ b/src/interfaces/libpq/fe-connect.c
@@ -491,7 +491,7 @@ PQconnectStartParams(const char **keywords,
{
conn->status = CONNECTION_BAD;
/* errorMessage is already set */
- return false;
+ return conn;
}
/*
--
1.7.1
Joseph Adams <joeyadams3.14159@gmail.com> writes:
I couldn't reproduce this (using upstream source on Ubuntu). However,
I did find a little bug in libpq causing the connection handle to
become NULL in the event of an option parsing error. This bug has
been around since release 9.0.0, and may be unrelated to the problem.
Yeah, that's clearly a bug --- fix committed, thanks for the patch!
It could explain Devrim's report if the parameters passed by psql had
some problem that was detectable by conninfo_array_parse(). That seems
a bit unlikely, but I did think of one possibility: if Devrim was
testing 9.1 psql with a 9.0 libpq (perhaps due to an rpath issue)
then 9.0 libpq would spit up on client_encoding, which wasn't a legal
connection parameter in 9.0.
regards, tom lane
On Sat, 2011-04-02 at 18:10 -0400, Tom Lane wrote:
It could explain Devrim's report if the parameters passed by psql had
some problem that was detectable by conninfo_array_parse(). That
seems a bit unlikely, but I did think of one possibility: if Devrim
was
testing 9.1 psql with a 9.0 libpq (perhaps due to an rpath issue)
then 9.0 libpq would spit up on client_encoding, which wasn't a legal
connection parameter in 9.0.
Bingo:
LD_LIBRARY_PATH=/usr/pgsql-9.1/lib/ psql -p 5433
worked. Let me fix the rpms.
Regards,
--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
Re: Tom Lane 2011-04-03 <1397.1301782258@sss.pgh.pa.us>
Yeah, that's clearly a bug --- fix committed, thanks for the patch!
It could explain Devrim's report if the parameters passed by psql had
some problem that was detectable by conninfo_array_parse(). That seems
a bit unlikely, but I did think of one possibility: if Devrim was
testing 9.1 psql with a 9.0 libpq (perhaps due to an rpath issue)
then 9.0 libpq would spit up on client_encoding, which wasn't a legal
connection parameter in 9.0.
Hi,
I'm still seeing that problem: 9.1 HEAD compiled in my $HOME, with
Debian's 9.0.1-2 libpq5 in /usr/lib:
$ LC_ALL=C bin/psql
psql: connection pointer is NULL
Upgrading to libpq5 9.0.4-1 makes things a bit better:
$ LC_ALL=C bin/psql
psql: invalid connection option "client_encoding"
Setting LD_LIBRARY_PATH fixes it.
Arguably, this is not the "standard" setup, but one that will probably
be quite frequent for someone trying 9.1 in their ~. Shouldn't psql
try to work with older libpq versions by omitting client_encoding?
Setting an RPATH seems like an ugly solution. (I'm not arguing for a
SONAME bump, but this is kind of an ABI change.)
Christoph
--
cb@df7cb.de | http://www.df7cb.de/
Christoph Berg <cb@df7cb.de> writes:
I'm still seeing that problem: 9.1 HEAD compiled in my $HOME, with
Debian's 9.0.1-2 libpq5 in /usr/lib:
$ LC_ALL=C bin/psql
psql: connection pointer is NULL
Upgrading to libpq5 9.0.4-1 makes things a bit better:
$ LC_ALL=C bin/psql
psql: invalid connection option "client_encoding"
Yes, this is unsurprising. The bug Joe Adams spotted was actually in
libpq 9.0.x, and it's fixed in 9.0.4. So now you get the expected
failure message instead of the opaque "connection pointer is NULL" one.
Arguably, this is not the "standard" setup, but one that will probably
be quite frequent for someone trying 9.1 in their ~. Shouldn't psql
try to work with older libpq versions by omitting client_encoding?
No. It has never been the expectation that psql could work with a libpq
older than its own release, and I see no reason to try to make it true
now. In most past versions the behavior would have been even less
friendly than this, ie a coredump due to unresolvable library symbols or
some such.
regards, tom lane