Horton

Thread

  1. psql 9.1 alpha5: connection pointer is NULL

    Devrim Gündüz <devrim@gunduz.org> — 2011-04-02T08:24:04Z

    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

  2. Re: psql 9.1 alpha5: connection pointer is NULL

    Joey Adams <joeyadams3.14159@gmail.com> — 2011-04-02T18:56:09Z

    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

  3. Re: psql 9.1 alpha5: connection pointer is NULL

    Tom Lane <tgl@sss.pgh.pa.us> — 2011-04-02T22:10:58Z

    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

  4. Re: psql 9.1 alpha5: connection pointer is NULL

    Devrim Gündüz <devrim@gunduz.org> — 2011-04-03T08:34:49Z

    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

  5. Re: psql 9.1 alpha5: connection pointer is NULL

    Christoph Berg <cb@df7cb.de> — 2011-04-22T11:35:44Z

    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/

  6. Re: psql 9.1 alpha5: connection pointer is NULL

    Tom Lane <tgl@sss.pgh.pa.us> — 2011-04-22T14:35:02Z

    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