Обсуждение: 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 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
Вложения
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