From: | Christoph Berg <cb(at)df7cb(dot)de> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: psql 9.1 alpha5: connection pointer is NULL |
Date: | 2011-04-22 11:35:44 |
Message-ID: | 20110422113544.GC3417@msgid.df7cb.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Re: Tom Lane 2011-04-03 <1397(dot)1301782258(at)sss(dot)pgh(dot)pa(dot)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(at)df7cb(dot)de | http://www.df7cb.de/
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2011-04-22 11:41:21 | Re: fsync reliability |
Previous Message | Deka, Rajib IN MAA SL | 2011-04-22 09:57:53 | Re: Re: database system identifier differs between the primary and standby |