Re: [HACKERS] psql 9.1 alpha5: connection pointer is NULL
Re: Tom Lane 2011-04-03 1397.1301782...@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 -- c...@df7cb.de | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: [HACKERS] psql 9.1 alpha5: connection pointer is NULL
Christoph Berg c...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql 9.1 alpha5: connection pointer is NULL
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 signature.asc Description: This is a digitally signed message part
[HACKERS] 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 signature.asc Description: This is a digitally signed message part
Re: [HACKERS] psql 9.1 alpha5: connection pointer is NULL
2011/4/2 Devrim GÜNDÜZ dev...@gunduz.org:
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?
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
From 5bcf99b6481dd1393525ee804eeae6a04999d86d Mon Sep 17 00:00:00 2001
From: Joey Adams joeyadams3.14...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql 9.1 alpha5: connection pointer is NULL
Joseph Adams joeyadams3.14...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
