Re: Hokey wrong versions of libpq in apt.postgresql.org

Hello,

I know this has been brought up before:

http://www.postgresql.org/message-id/20140724080902.GA28113@msg.df7cb.de

But this is just plain wrong. I don't care that the FAQ (on the wiki)
says we are doing it wrong for good reasons. When I (or anyone else)
pulls postgresql-$version-dev, I want the libpq for my version. I do not
want 9.3.

Yes, it "should" (because of protocol compatibility) work but it doesn't
always (as stated in that email and in a similar problem we just ran into).

There can be unintended circumstances on machines when you mix and match
like that. Can we please do some proper packaging on this?

Sincerely,

Joshua D. Drake
--
Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564
PostgreSQL Support, Training, Professional Services and Development
High Availability, Oracle Conversion, @cmdpromptinc
"If we send our children to Caesar for their education, we should
not be surprised when they come back as Romans."

JD,

* Joshua D. Drake (jd(at)commandprompt(dot)com) wrote:
> But this is just plain wrong. I don't care that the FAQ (on the
> wiki) says we are doing it wrong for good reasons. When I (or anyone
> else) pulls postgresql-$version-dev, I want the libpq for my
> version. I do not want 9.3.

No, it isn't wrong. If you'd like the specific version, follow what's
in the FAQ to get the specific version. Otherwise, we're going to
follow the Debian guidelines which are quite sensible and more-or-less
say "make new builds go against the latest version".

> There can be unintended circumstances on machines when you mix and
> match like that. Can we please do some proper packaging on this?

This *is* the proper packaging.

If you want the specific version, update your deb line. Don't complain
because you used the Debian repo that follows the Debian guidelines and
didn't like what you got- that's not going to change.

Thanks,

Stephen

On 08/07/2014 10:12 PM, Stephen Frost wrote:

> If you want the specific version, update your deb line. Don't complain
> because you used the Debian repo that follows the Debian guidelines and
> didn't like what you got- that's not going to change.

May I have a link? Because I would argue that the "latest" version of
the library for 9.2, is the library that ships with 9.2.9, not the one
that ships with 9.3.5.

JD

--
Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564
PostgreSQL Support, Training, Professional Services and Development
High Availability, Oracle Conversion, @cmdpromptinc
"If we send our children to Caesar for their education, we should
not be surprised when they come back as Romans."

* Joshua D. Drake (jd(at)commandprompt(dot)com) wrote:
> On 08/07/2014 10:12 PM, Stephen Frost wrote:
> >If you want the specific version, update your deb line. Don't complain
> >because you used the Debian repo that follows the Debian guidelines and
> >didn't like what you got- that's not going to change.
>
> May I have a link? Because I would argue that the "latest" version
> of the library for 9.2, is the library that ships with 9.2.9, not
> the one that ships with 9.3.5.

Really? The latest version of libpq SO version 5 that we ship is 9.2.9?
I certainly don't feel that way.

Next you'll be asking us to bump the major SO for every major release of
PG.

Note that the last time we changed the SO major version was back in 2006
and that was primairly because we were removing symbols that people
weren't supposed to be using anyway. Prior to that, it was 2005, or the
8.0/8.1 timeframe...

Thanks,

Stephen

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Joshua D. Drake (jd(at)commandprompt(dot)com) wrote:
>> On 08/07/2014 10:12 PM, Stephen Frost wrote:
>>> If you want the specific version, update your deb line. Don't complain
>>> because you used the Debian repo that follows the Debian guidelines and
>>> didn't like what you got- that's not going to change.

>> May I have a link? Because I would argue that the "latest" version
>> of the library for 9.2, is the library that ships with 9.2.9, not
>> the one that ships with 9.3.5.

> Really? The latest version of libpq SO version 5 that we ship is 9.2.9?
> I certainly don't feel that way.

> Next you'll be asking us to bump the major SO for every major release of
> PG.

> Note that the last time we changed the SO major version was back in 2006
> and that was primairly because we were removing symbols that people
> weren't supposed to be using anyway. Prior to that, it was 2005, or the
> 8.0/8.1 timeframe...

We only bump the SO version when we make a low-level ABI break; but even
without doing that we could potentially have changed library behavior in
ways that could negatively impact some applications. So I think there's
some merit in Josh's position: he doesn't want to have to re-QA his
applications against some new version of libpq, but if you force him to
move to 9.3 libpq, he's going to need to do that if he wants to be strict
about it. If the Debian guidelines think that only SO major version need
be considered, they're wrong, at least for the way we've been treating
that.

At the same time, there would be more merit in Josh's position if he
could point to any *actual* libpq changes that might pose application
compatibility problems. I don't recall that we've made many such,
so the above argument might just be hypothetical.

regards, tom lane

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> We only bump the SO version when we make a low-level ABI break; but even
> without doing that we could potentially have changed library behavior in
> ways that could negatively impact some applications.

We should definitely be paying attention for such cases as I'd generally
feel that they're bug fixes we need to address..

> So I think there's
> some merit in Josh's position: he doesn't want to have to re-QA his
> applications against some new version of libpq, but if you force him to
> move to 9.3 libpq, he's going to need to do that if he wants to be strict
> about it.

"Force" is a bit strong here, in my opinion. There's a (really, rather
trivial) way to get the libpq version which is shipped with a specific
PG major version- simple add that major version to the end of the 'deb'
line in your sources.list file.

> If the Debian guidelines think that only SO major version need
> be considered, they're wrong, at least for the way we've been treating
> that.

The SO major version should be sufficient for applications to operate
normally. If that isn't the case then I agree that we need to review
the changes we are making to see if the SO should be bumped. Note that
Debian's viewpoint on this is more along the lines of "why build against
an old version if the latest one, whose major SO is the same, exists?"
This is largely to avoid the hell of versioned Build-Depends and having
to support multiple sets of -dev packages concurrently (consider that
builds generally only look for the unversioned '.so' file also..).

> At the same time, there would be more merit in Josh's position if he
> could point to any *actual* libpq changes that might pose application
> compatibility problems. I don't recall that we've made many such,
> so the above argument might just be hypothetical.

I don't believe it's hypothetical from Josh's perspective, but I didn't
follow the threads completely to confirm that there was a real issue.
If there is a real issue here, I'd most likely vote to fix it and
backpatch it as a bug, though it's not clear if that would be considered
'good enough' for this case.

Thanks,

Stephen

> The SO major version should be sufficient for applications to operate
> normally. If that isn't the case then I agree that we need to review
> the changes we are making to see if the SO should be bumped. Note that
> Debian's viewpoint on this is more along the lines of "why build against
> an old version if the latest one, whose major SO is the same, exists?"
> This is largely to avoid the hell of versioned Build-Depends and having
> to support multiple sets of -dev packages concurrently (consider that
> builds generally only look for the unversioned '.so' file also..).
>
>> At the same time, there would be more merit in Josh's position if he
>> could point to any *actual* libpq changes that might pose application
>> compatibility problems. I don't recall that we've made many such,
>> so the above argument might just be hypothetical.
>
> I don't believe it's hypothetical from Josh's perspective, but I didn't
> follow the threads completely to confirm that there was a real issue.
> If there is a real issue here, I'd most likely vote to fix it and
> backpatch it as a bug, though it's not clear if that would be considered
> 'good enough' for this case.

The issue that I specifically ran into is that by using
apt.postgresql.org in its default configuration, I can't add certain
extensions (without jumping through hoops). Simple:

Assume a running 9.2.9 from apt.postgresql.org
apt-get install pgxnclient
sudo pgxnclient install pg_repack

....

Doesn't work. Because it is looking for libs in /var/lib/postgresql/9.2
not /var/lib/postgresql/9.3.

It also failed on another extension (but I don't recall which one it is).

Yes. I can get the 9.2 libpq but that isn't really the point is it? This
is quite unexpected behavior from an operational perspective. It should
just "work" but it doesn't because we are shipping from
apt.postgresql.org a 9.3 version of libpq.

(protocol versions don't really matter here, this is an operational thing).

Sincerely,

Joshua D. Drake

>
> Thanks,
>
> Stephen
>

--
Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564
PostgreSQL Support, Training, Professional Services and Development
High Availability, Oracle Conversion, @cmdpromptinc
"If we send our children to Caesar for their education, we should
not be surprised when they come back as Romans."

JD,

* Joshua D. Drake (jd(at)commandprompt(dot)com) wrote:
> The issue that I specifically ran into is that by using
> apt.postgresql.org in its default configuration, I can't add certain
> extensions (without jumping through hoops). Simple:
>
> Assume a running 9.2.9 from apt.postgresql.org
> apt-get install pgxnclient
> sudo pgxnclient install pg_repack
>
> ....
>
> Doesn't work. Because it is looking for libs in
> /var/lib/postgresql/9.2 not /var/lib/postgresql/9.3.

Have you got any postgresql-server-dev package installed? If not, then
pg_config is going to grab the info for the libpq-dev that's installed,
but I doubt the extension is going to compile without the server-dev
package installed anyway..

In any case, pgxnclient should probably be more intelligent when it's
working under a Debian-based installation where multiple major versions
of PG can be installed.

> Yes. I can get the 9.2 libpq but that isn't really the point is it?
> This is quite unexpected behavior from an operational perspective.
> It should just "work" but it doesn't because we are shipping from
> apt.postgresql.org a 9.3 version of libpq.

I don't believe the 9.3 version of libpq is the issue here at all, see
above..

Thanks,

Stephen

Re: Joshua D. Drake 2014-08-11 <53E83E9C(dot)6030107(at)commandprompt(dot)com>
> The issue that I specifically ran into is that by using apt.postgresql.org
> in its default configuration, I can't add certain extensions (without
> jumping through hoops). Simple:
>
> Assume a running 9.2.9 from apt.postgresql.org
> apt-get install pgxnclient
> sudo pgxnclient install pg_repack
>
> ....
>
> Doesn't work. Because it is looking for libs in /var/lib/postgresql/9.2 not
> /var/lib/postgresql/9.3.
>
> It also failed on another extension (but I don't recall which one it is).

I'd be interested in which other extension this is. As I told you
repeatedly, we are building tons of extensions for something like 5
branches in parallel on apt.postgresql.org, and things generally just
work.

We don't have pg_repack packages there, but there is pg_reorg. This
indeed required some patch to compile, namely manual pg_config_ext.h
and postgres_ext.h includes:
http://anonscm.debian.org/cgit/pkg-postgresql/pg-reorg.git/tree/debian/patches/headers

Trying pg_repack manually here yields this:

pg_repack-1.2.1/bin $ make
gcc -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -fPIC -pie -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g -I/usr/include/postgresql -DREPACK_VERSION=1.2.1 -I. -I. -I/usr/include/postgresql/9.1/server -I/usr/include/postgresql/internal -D_FORTIFY_SOURCE=2 -DLINUX_OOM_ADJ=0 -D_GNU_SOURCE -I/usr/include/libxml2 -I/usr/include/tcl8.5 -c -o pgut/pgut.o pgut/pgut.c
In file included from pgut/pgut.c:10:0:
/usr/include/postgresql/postgres_fe.h:27:32: fatal error: common/fe_memutils.h: No such file or directory

This can be fixed by moving -I/usr/include/postgresql past the server
includes, but then there's other issues:

$ gcc -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -fPIC -pie -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g -DREPACK_VERSION=1.2.1 -I. -I. -I/usr/include/postgresql/9.1/server -I/usr/include/postgresql/internal -I/usr/include/postgresql -D_FORTIFY_SOURCE=2 -DLINUX_OOM_ADJ=0 -D_GNU_SOURCE -I/usr/include/libxml2 -I/usr/include/tcl8.5 -c -o pgut/pgut.o pgut/pgut.c
In file included from pgut/pgut.h:23:0,
from pgut/pgut.c:17:
/usr/include/postgresql/libpq-fe.h:547:1: error: unknown type name 'pg_int64'
/usr/include/postgresql/libpq-fe.h:547:50: error: unknown type name 'pg_int64'
/usr/include/postgresql/libpq-fe.h:551:1: error: unknown type name 'pg_int64'
/usr/include/postgresql/libpq-fe.h:553:48: error: unknown type name 'pg_int64'

This seems to be another instance of the "(includedir_internal)
headers are not self-contained" problem, see
http://www.postgresql.org/message-id/20140426122548.GA7249@msgid.df7cb.de

Possibly we need to move some files in libpq-dev to/from
postgresql-server-dev-*, though I believe the Debian packages are now
just replicating whatever header layout the PostgreSQL makefiles
construct on install. (Namely server -> /usr/include/postgresql/9.4/server,
Rest -> /usr/include/postgresql/)

I haven't tried to check all include paths with various combinations
of libpq-dev and postgresql-server-dev-one-or-the-other-version
installed, though that would be an interesting exercise. Any
volunteers?

Christoph
--
cb(at)df7cb(dot)de | http://www.df7cb.de/

On 08/07/2014 04:30 PM, Joshua D. Drake wrote:
>
> Hello,
>
> I know this has been brought up before:
>
> http://www.postgresql.org/message-id/20140724080902.GA28113@msg.df7cb.de

For reference, libpq and packaging issues discussed here as well:
http://www.postgresql.org/message-id/53A304BC.40908@pinpointresearch.com
http://www.postgresql.org/message-id/53989C91.6050403@pinpointresearch.com

>
> But this is just plain wrong. I don't care that the FAQ (on the wiki)
> says we are doing it wrong for good reasons. When I (or anyone else)
> pulls postgresql-$version-dev, I want the libpq for my version. I do
> not want 9.3.
>
> Yes, it "should" (because of protocol compatibility) work but it
> doesn't always (as stated in that email and in a similar problem we
> just ran into).
>
> There can be unintended circumstances on machines when you mix and
> match like that. Can we please do some proper packaging on this?

+1

Cheers,
Steve

On 08/12/2014 10:26 AM, Steve Crawford wrote:
>
> On 08/07/2014 04:30 PM, Joshua D. Drake wrote:
>>
>> Hello,
>>
>> I know this has been brought up before:
>>
>> http://www.postgresql.org/message-id/20140724080902.GA28113@msg.df7cb.de
>
> For reference, libpq and packaging issues discussed here as well:
> http://www.postgresql.org/message-id/53A304BC.40908@pinpointresearch.com
> http://www.postgresql.org/message-id/53989C91.6050403@pinpointresearch.com
>
>>
>> But this is just plain wrong. I don't care that the FAQ (on the wiki)
>> says we are doing it wrong for good reasons. When I (or anyone else)
>> pulls postgresql-$version-dev, I want the libpq for my version. I do
>> not want 9.3.

I am finally able to get back around to this and I am still calling:
Hokey. I just loaded up a fresh precise (I assume trusty will act the
same way) and installed postgresql. I installed it, without the PDGD
repository and everything worked perfectly. The only error I got when
using pgxnclient to install pg_repack was an error about not having
libedit-dev installed. I installed it, and it was perfect. I even tested
with create extension etc...

So... If we are supposed to ship the "latest" lib... how come Debian or
Ubuntu don't do that? They ship the latest lib for the version they are
shipping and because of that, everything works, as expected.

I iterate, the current apt.postgresql.org is not doing things correctly.
It breaks things and it shouldn't.

Sincerely,

Joshua D. Drake

--
Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564
PostgreSQL Support, Training, Professional Services and Development
High Availability, Oracle Conversion, @cmdpromptinc
"If we send our children to Caesar for their education, we should
not be surprised when they come back as Romans."

On 08/19/2014 05:02 AM, Joshua D. Drake wrote:
>
> I am finally able to get back around to this and I am still calling:
> Hokey. I just loaded up a fresh precise (I assume trusty will act the
> same way) and installed postgresql. I installed it, without the PDGD
> repository and everything worked perfectly. The only error I got when
> using pgxnclient to install pg_repack was an error about not having
> libedit-dev installed. I installed it, and it was perfect. I even tested
> with create extension etc...
>
> So... If we are supposed to ship the "latest" lib... how come Debian or
> Ubuntu don't do that? They ship the latest lib for the version they are
> shipping and because of that, everything works, as expected.
>
> I iterate, the current apt.postgresql.org is not doing things correctly.
> It breaks things and it shouldn't.

FWIW, this is inconsistent with what yum.postgresql.org does - it takes
the POLA approach of packing the libpq from the major release configured
in the repo. Each major has its own sub-repo.

I find it pretty hard to justify installing a 9.3 libpq alongside a 9.1
server myself.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

On 08/19/2014 08:34 AM, Craig Ringer wrote:

>> I iterate, the current apt.postgresql.org is not doing things correctly.
>> It breaks things and it shouldn't.
>
> FWIW, this is inconsistent with what yum.postgresql.org does - it takes
> the POLA approach of packing the libpq from the major release configured
> in the repo. Each major has its own sub-repo.
>
> I find it pretty hard to justify installing a 9.3 libpq alongside a 9.1
> server myself.
>

Exactly.

JD

--
Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564
PostgreSQL Support, Training, Professional Services and Development
High Availability, Oracle Conversion, @cmdpromptinc
"If we send our children to Caesar for their education, we should
not be surprised when they come back as Romans."

On Sat, Aug 9, 2014 at 2:23 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> If the Debian guidelines think that only SO major version need
> be considered, they're wrong, at least for the way we've been treating
> that.

The Debian approach is that you should have precisely one installed
copy of a library for each soname. I guess there's no particular
reason you can't have multiple versions in the repository (possiby
built by different source packages) but users will only be able to
install one of them. This follows from there being a single /usr/lib
and ldconfig picking a single version for each soname.

--
greg