Thread: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)

[Taken off GENERAL, added HACKERS to cc:]

Bruce Momjian wrote:
> > He's meaning the libpq version for dynamic link loading.  Is the
> > libpq.so lib changing versions (like the change from 6.5.x to 7.0.x
> > changed from libpq.so.2.0 to libpq.so.2.1, which broke binary RPM
> > compatibility for other RPM's linked against libpq.so.2.0, which failed
> > when libpq.so.2.1 came on the scene).  I think the answer is no, but I
> > haven't checked the details yet.
> I usually up the .so version numbers before entering beta.  That way,
> they get marked as newer than older versions.

May I ask: is it necessary?  Have there been version-bumping changes to
libpq since 7.0.x? (With the rate that necessary improvement is
happening to PostgreSQL, probably).

Let me explain:
RPM's contain a plethora of dependency information, some of which is
added manually, but most of which is generated automatically.  These
dependencies are based on which 'soname' is needed to satisfy dynamic
linking requirements, interpreter requirements, etc.  With version
numbers as part of the name, a change in version numbers changes the
dependency.  
Unfortunately RPM deems a dependency upon libpq.so.2.0 to not be
fulfilled by libpq.so.2.1 (how _can_ it know?  A client linked to 2.0
might fail if 2.1 were to be loaded under it (hypothetically)).

Now, that doesn't directly effect the PostgreSQL RPM's.  What it does
effect is the guy who wants to install PHP from  with PostgreSQL support
enabled and cannot because of a failed dependency. Who gets blamed?
PostgreSQL.

Trond may correct me on this, but I don't know of a workaround for
this.  And any workaround has to be applied to packages that depend upon
PostgreSQL, not to the PostgreSQL RPM's (which I would gladly modify) --
although I am going to try something -- I know that a symlink to the old
soname works, even though it is a kludge and, IMO, stinks like a
polecat.

But, enough rant.  That _is_ I believe what Trond was asking about.  We
have been bitten before with people installing the PHP from RedHat 6.2
after installing the PostgreSQL 7.0.x RPMset -- and dependency failures
wreaked havoc.

So, PostgreSQL 7.1 is slated to be libpq.so.2.2, then?

Actually, Bruce, it would do me and Trond a great favor if a list of
what so's are getting bumped and to what version were to be posted.  At
least we can plan for a transition at that point.  

I just hate to pull a threepeat on RedHat customers. (RH 5.0 shipped PG
6.2.1.  RH 5.1 shipped PG 6.3.2. BONG!) (RH 6.0 shipped 6.4.2 (bong!) RH
6.1 shipped 6.5.2 (double BONG!)).  RH 7 shipped 7.0.x (small bong) --
RH 7.1 ships 7.1.x (ouch bong).

Whew.  Trond, you ready for this?

[Note: I have been ill, so this message may be more incoherent than my
normal scattered self]
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Lamar Owen <lamar.owen@wgcr.org> writes:
> Unfortunately RPM deems a dependency upon libpq.so.2.0 to not be
> fulfilled by libpq.so.2.1 (how _can_ it know?  A client linked to 2.0
> might fail if 2.1 were to be loaded under it (hypothetically)).

If so, I claim RPM is broken.

The whole point of major/minor version numbering for .so's is that
a minor version bump is supposed to be binary-upward-compatible.
If the RPM stuff has arbitrarily decided that it won't honor that
definition, why do we bother with multiple numbers at all?

> So, PostgreSQL 7.1 is slated to be libpq.so.2.2, then?

To answer your question, there are no pending changes in libpq that
would mandate a major version bump (ie, nothing binary-incompatible,
AFAIK).  We could ship it with the exact same version number, but then
how are people to tell whether they have a 7.0 or 7.1 libpq?
        regards, tom lane

> Lamar Owen <lamar.owen@wgcr.org> writes:
> > Unfortunately RPM deems a dependency upon libpq.so.2.0 to not be
> > fulfilled by libpq.so.2.1 (how _can_ it know?  A client linked to 2.0
> > might fail if 2.1 were to be loaded under it (hypothetically)).
> 
> If so, I claim RPM is broken.
> 
> The whole point of major/minor version numbering for .so's is that
> a minor version bump is supposed to be binary-upward-compatible.
> If the RPM stuff has arbitrarily decided that it won't honor that
> definition, why do we bother with multiple numbers at all?
> 
> > So, PostgreSQL 7.1 is slated to be libpq.so.2.2, then?
> 
> To answer your question, there are no pending changes in libpq that
> would mandate a major version bump (ie, nothing binary-incompatible,
> AFAIK).  We could ship it with the exact same version number, but then
> how are people to tell whether they have a 7.0 or 7.1 libpq?

Yes, we need to have new numbers so binaries from different releases use
the proper .so files.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 

Tom Lane <tgl@sss.pgh.pa.us> writes:

> Lamar Owen <lamar.owen@wgcr.org> writes:
> > Unfortunately RPM deems a dependency upon libpq.so.2.0 to not be
> > fulfilled by libpq.so.2.1 (how _can_ it know?  A client linked to 2.0
> > might fail if 2.1 were to be loaded under it (hypothetically)).

You link against libpq.so.2 , not libpq.so.2.1. This isn't a problem.

> If the RPM stuff has arbitrarily decided that it won't honor that
> definition, why do we bother with multiple numbers at all?

There is no such problem.
> > So, PostgreSQL 7.1 is slated to be libpq.so.2.2, then?
> 
> To answer your question, there are no pending changes in libpq that
> would mandate a major version bump (ie, nothing binary-incompatible,
> AFAIK).  We could ship it with the exact same version number, but then
> how are people to tell whether they have a 7.0 or 7.1 libpq?

If there isn't any changes, why bump it? 
-- 
Trond Eivind Glomsrød
Red Hat, Inc.

> > To answer your question, there are no pending changes in libpq that
> > would mandate a major version bump (ie, nothing binary-incompatible,
> > AFAIK).  We could ship it with the exact same version number, but then
> > how are people to tell whether they have a 7.0 or 7.1 libpq?
> 
> If there isn't any changes, why bump it? 

This is huge software.  There are changes to every library in every
major release, major for us meaning, i.e., 7.0->7.1.  That is why I bump
the numbers.

The interesting issue is that the version number changes for .so do
_not_ mean they only talk with servers of the same release.  They will
talk to future servers of higher release numbers.  This is done because
there is a backend protocol number that is passed from client to server
which determines how the server should behave with that client.

We can't always have new clients talking to older servers because the
old servers may not know the newer protocol.  We could get fancy and
trade version numbers and try to get it working, but it has not been a
priority, and few have asked for it.  Having old clients talking to new
databases has been enough for most users.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 

Lamar Owen <lamar.owen@wgcr.org> writes:

> Unfortunately RPM deems a dependency upon libpq.so.2.0 to not be
> fulfilled by libpq.so.2.1 (how _can_ it know?  A client linked to 2.0
> might fail if 2.1 were to be loaded under it (hypothetically)).
> 
> Now, that doesn't directly effect the PostgreSQL RPM's.  What it does
> effect is the guy who wants to install PHP from  with PostgreSQL support
> enabled and cannot because of a failed dependency. Who gets blamed?
> PostgreSQL.
> 
> Trond may correct me on this, but I don't know of a workaround for
> this. 

There usually are no such problems, and I'm not aware of any specific
to postgresql either.

-- 
Trond Eivind Glomsrød
Red Hat, Inc.

Tom Lane wrote:
> 
> Lamar Owen <lamar.owen@wgcr.org> writes:
> > Unfortunately RPM deems a dependency upon libpq.so.2.0 to not be
> > fulfilled by libpq.so.2.1 (how _can_ it know?  A client linked to 2.0
> > might fail if 2.1 were to be loaded under it (hypothetically)).
> 
> If so, I claim RPM is broken.
> 
> The whole point of major/minor version numbering for .so's is that
> a minor version bump is supposed to be binary-upward-compatible.
> If the RPM stuff has arbitrarily decided that it won't honor that
> definition, why do we bother with multiple numbers at all?
> 
> > So, PostgreSQL 7.1 is slated to be libpq.so.2.2, then?
> 
> To answer your question, there are no pending changes in libpq that
> would mandate a major version bump (ie, nothing binary-incompatible,
> AFAIK).  We could ship it with the exact same version number, but then
> how are people to tell whether they have a 7.0 or 7.1 libpq?

And that is a very good point.  Hey, I'm caught in the middle here :-).
I want to see PostgreSQL succeed and excel (which, to me, means becoming
the RDBMS of choice) on RPM-based Linux distributions, which I am sure
is a goal of others too.  And I'm sure no one here is against that.

But, there is friction between RedHat's (to use the first example of a
distributor to pop into my head) needs and the needs of the PostgreSQL
group.

My gut feel is that RedHat may be better off shipping 7.0.x if the
library version numbers are a contributory problem.  The data upgrade
problem is a bigger problem.  To which RedHat might just want to stay at
7.0.x until either a tool is written to painlessly migrate or until the
next major RedHat is released.

Of course, that doesn't affect what I do as far as building 7.1 RPM's
for distribution from the PostgreSQL site (or by anyone who so desires
to distribute them).  I have no choice for my own self but to stay on
the curve.  I need TOAST and OUTER JOINS too much.

So, what I feel may be the best compromise is for RedHat (and myself) to
continue building 7.0.x RPM's with bugfixes, etc, while I build 7.1 ad
subsequent RPMset's for those who know what they're doing and not
blindly upgrading their systems.

Trond, do you have any comments on that?  Or is the likely migration to
kernel 2.4 in the next RedHat going to make a compatability compromise
here moot?
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Lamar Owen <lamar.owen@wgcr.org> writes:

> My gut feel is that RedHat may be better off shipping 7.0.x if the
> library version numbers are a contributory problem.  

We could provide compat-packages with just neeeded libraries.

> The data upgrade problem is a bigger problem.  To which RedHat might
> just want to stay at  7.0.x until either a tool is written to
> painlessly migrate or until the  next major RedHat is released.

We upgrade everything from 3.0.3 (we no longer support upgrades from
2.0 as we couldn't find a specific way to identify such a system and
we didn't want accidentaly upgrade other distributions), so there is
pain anyway.

> Of course, that doesn't affect what I do as far as building 7.1 RPM's
> for distribution from the PostgreSQL site (or by anyone who so desires
> to distribute them).  I have no choice for my own self but to stay on
> the curve.  I need TOAST and OUTER JOINS too much.

Others very likely have the same need. I'll be looking into issues
with these later.
> So, what I feel may be the best compromise is for RedHat (and myself) to
> continue building 7.0.x RPM's with bugfixes, etc, while I build 7.1 ad
> subsequent RPMset's for those who know what they're doing and not
> blindly upgrading their systems.

> Trond, do you have any comments on that?  Or is the likely migration to
> kernel 2.4 in the next RedHat going to make a compatability compromise
> here moot?

No, the 2.4 kernel should go right in - I've been using it extensively
on my system until recently (the most recent pretest has problems with
flock for sendmail).


Anyway, I've had a look at psql in objdump:

Dynamic Section: NEEDED      libpq.so.2.1 NEEDED      libcrypt.so.1 NEEDED      libnsl.so.1 NEEDED      libdl.so.2
NEEDED     libm.so.6 NEEDED      libutil.so.1 NEEDED      libreadline.so.4.1 NEEDED      libtermcap.so.2 NEEDED
libncurses.so.5NEEDED      libc.so.6
 

[...]

It links against nice, round versions of most libraries but wants
specific versions of readline ad libpq.

-- 
Trond Eivind Glomsrød
Red Hat, Inc.

Trond Eivind Glomsrød wrote:
> Lamar Owen <lamar.owen@wgcr.org> writes:
> > Unfortunately RPM deems a dependency upon libpq.so.2.0 to not be
> > fulfilled by libpq.so.2.1 (how _can_ it know?  A client linked to 2.0
> > might fail if 2.1 were to be loaded under it (hypothetically)).

> There usually are no such problems, and I'm not aware of any specific
> to postgresql either.

There have been reports to the pgsql-bugs list and to the PHP list about
this very issue.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

[BCC to Hackers -- cc: to PORTS, as, as Bruce correctly pointed out,
that's where this discussion belongs.]

Trond Eivind Glomsrød wrote:
> Lamar Owen <lamar.owen@wgcr.org> writes:
> > My gut feel is that RedHat may be better off shipping 7.0.x if the
> > library version numbers are a contributory problem.

> We could provide compat-packages with just neeeded libraries.

Yes, we could do that.  And those libs could possibly just be the
symlinks (or even just a Provides: header).

> We upgrade everything from 3.0.3 (we no longer support upgrades from
> 2.0 as we couldn't find a specific way to identify such a system and
> we didn't want accidentaly upgrade other distributions), so there is
> pain anyway.

I tried going from 4.1 (the earliest one I have installation CD's for)
to pre-7.0 once.  I don't recommend it.

> > Of course, that doesn't affect what I do as far as building 7.1 RPM's
> > for distribution from the PostgreSQL site (or by anyone who so desires
> > to distribute them).  I have no choice for my own self but to stay on
> > the curve.  I need TOAST and OUTER JOINS too much.

> Others very likely have the same need. I'll be looking into issues
> with these later.

Good. Let me know what you decide, if you don't mind.

> Anyway, I've had a look at psql in objdump:

> Dynamic Section:
>   NEEDED      libpq.so.2.1
>   NEEDED      libreadline.so.4.1
> [...]

> It links against nice, round versions of most libraries but wants
> specific versions of readline ad libpq.

And unfortunately PHP and other PostgreSQL clients also link against the
specific libpq version.  This has caused pain for those installing the
PHP stuff from RPM which was linked against a RedHat 6.2 box with
PostgreSQL 6.5.3 installed -- onto a RedHat 6.2 box with PostgreSQL
7.0.2 installed.  There is a failed dependency on libpq.so.2.0 -- even
though libpq.so.2.1 is there.

A symlink works around the problem, if the symlink is part of the RPM so
that it gets in the rpm dep database.  Of course, this only causes
problems with RedHat 6.2 and earlier, as RH 7's PHP stuff was built
against 7.0.2 to start with.  But, 7.1 with libpq.so.2.2 will cause
similar dep failures for PHP packages built against 7.0.2.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11