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

2014-08-20 Thread Greg Stark
On Sat, Aug 9, 2014 at 2:23 AM, Tom Lane t...@sss.pgh.pa.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


-- 
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] Hokey wrong versions of libpq in apt.postgresql.org

2014-08-19 Thread Craig Ringer
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


-- 
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] Hokey wrong versions of libpq in apt.postgresql.org

2014-08-19 Thread Joshua D. Drake


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.


--
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] Hokey wrong versions of libpq in apt.postgresql.org

2014-08-18 Thread Joshua D. Drake


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.ga28...@msg.df7cb.de


For reference, libpq and packaging issues discussed here as well:
http://www.postgresql.org/message-id/53a304bc.40...@pinpointresearch.com
http://www.postgresql.org/message-id/53989c91.6050...@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.


--
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] Hokey wrong versions of libpq in apt.postgresql.org

2014-08-12 Thread Christoph Berg
Re: Joshua D. Drake 2014-08-11 53e83e9c.6030...@commandprompt.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.ga7...@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
-- 
c...@df7cb.de | http://www.df7cb.de/


-- 
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] Hokey wrong versions of libpq in apt.postgresql.org

2014-08-12 Thread Steve Crawford

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.ga28...@msg.df7cb.de


For reference, libpq and packaging issues discussed here as well:
http://www.postgresql.org/message-id/53a304bc.40...@pinpointresearch.com
http://www.postgresql.org/message-id/53989c91.6050...@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


--
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] Hokey wrong versions of libpq in apt.postgresql.org

2014-08-11 Thread Stephen Frost
JD,

* Joshua D. Drake (j...@commandprompt.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


signature.asc
Description: Digital signature


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

2014-08-10 Thread Joshua D. Drake




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.


--
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] Hokey wrong versions of libpq in apt.postgresql.org

2014-08-08 Thread Joshua D. Drake


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.


--
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] Hokey wrong versions of libpq in apt.postgresql.org

2014-08-08 Thread Stephen Frost
* Joshua D. Drake (j...@commandprompt.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


signature.asc
Description: Digital signature


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

2014-08-08 Thread Tom Lane
Stephen Frost sfr...@snowman.net writes:
 * Joshua D. Drake (j...@commandprompt.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


-- 
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] Hokey wrong versions of libpq in apt.postgresql.org

2014-08-08 Thread Stephen Frost
* Tom Lane (t...@sss.pgh.pa.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


signature.asc
Description: Digital signature


[HACKERS] Hokey wrong versions of libpq in apt.postgresql.org

2014-08-07 Thread Joshua D. Drake


Hello,

I know this has been brought up before:

http://www.postgresql.org/message-id/20140724080902.ga28...@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.


--
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] Hokey wrong versions of libpq in apt.postgresql.org

2014-08-07 Thread Stephen Frost
JD,

* Joshua D. Drake (j...@commandprompt.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


signature.asc
Description: Digital signature