PQnotifies() in 7.3 broken?
Thanks to Rod Taylor's kind help in donating a system account, I've been
able to test libpqxx against postgres 7.3. Unfortunately, I'm running
into several problems. One thing that broke libpqxx was a change in
cursor behaviour that according to Sigurdur Gunnlaugsson seems to be
gone in the 7.4 development tree. But I'm hitting other snags as well.
When receiving a trigger notification under 7.3, the structure returned
by PQnotifies() appears to be bogus. In a test I ran, its be_pid was
consistently zero and its relname pointed into never-neverland.
Has anyone else come across this?
Jeroen
"Jeroen T. Vermeulen" <jtv@xs4all.nl> writes:
When receiving a trigger notification under 7.3, the structure returned
by PQnotifies() appears to be bogus. In a test I ran, its be_pid was
consistently zero and its relname pointed into never-neverland.
We changed the PQnotifies result structure in 7.3 (to insulate clients
from the value of NAMEDATALEN). I think you are compiling your app with
a 7.3 libpq header and then running it with 7.2 libpq code, or possibly
vice versa.
regards, tom lane
Perhaps the .so name should have been updated for PostgreSQL 7.3? For
example in 7.2 libpq is:
/usr/lib/libpq.so -> libpq.so.2.2
/usr/lib/libpq.so.2 -> libpq.so.2.2
/usr/lib/libpq.so.2.0 -> libpq.so.2
/usr/lib/libpq.so.2.2
and PostgreSQL 7.3:
/usr/lib/libpq.so -> libpq.so.2.2
/usr/lib/libpq.so.2 -> libpq.so.2.2
/usr/lib/libpq.so.2.0 -> libpq.so.2
/usr/lib/libpq.so.2.2
the same. This would seem to imply binary compatibility?
Lee.
Tom Lane writes:
Show quoted text
"Jeroen T. Vermeulen" <jtv@xs4all.nl> writes:
When receiving a trigger notification under 7.3, the structure returned
by PQnotifies() appears to be bogus. In a test I ran, its be_pid was
consistently zero and its relname pointed into never-neverland.We changed the PQnotifies result structure in 7.3 (to insulate clients
from the value of NAMEDATALEN). I think you are compiling your app with
a 7.3 libpq header and then running it with 7.2 libpq code, or possibly
vice versa.
Lee Kindness <lkindness@csl.co.uk> writes:
Perhaps the .so name should have been updated for PostgreSQL 7.3?
It should have been. If it wasn't, that was a serious oversight.
Not sure if we should change it in 7.3.1 or not, though; it may be
too late for that. Any thoughts out there?
regards, tom lane
Tom Lane wrote:
Lee Kindness <lkindness@csl.co.uk> writes:
Perhaps the .so name should have been updated for PostgreSQL 7.3?
It should have been. If it wasn't, that was a serious oversight.
Not sure if we should change it in 7.3.1 or not, though; it may be
too late for that. Any thoughts out there?
Seems I did forget. I always update the minor for a major release, but
when development starts, and I seem to have forgotten for 7.3. Sorry.
I will update for 7.4 now. Too late for 7.3 clearly.
Turns out I usually do it when I stamp the new development tree, but
someone else stamped 7.3 and 7.4. :-(
Here is 7.2 stamp, which shows the updates:
revision 1.52
date: 2001/05/11 01:46:33; author: momjian; state: Exp; lines: +2 -2
Stamp CVS as 7.2. Update all interface version numbers. This is the
time to do it, not during beta because people are using this stuff in
production sometimes.
The diff shows:
***************
*** 15,21 ****
# shared library parameters
NAME= pq
SO_MAJOR_VERSION= 2
! SO_MINOR_VERSION= 1
override CPPFLAGS := -I$(srcdir) $(CPPFLAGS) -DFRONTEND
-DSYSCONFDIR='"$(sysco
nfdir)"'
--- 15,21 ----
# shared library parameters
NAME= pq
SO_MAJOR_VERSION= 2
! SO_MINOR_VERSION= 2so clearly 7.2 and 7.3 have the same minor version for all interfaces. Bad!
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian writes:
so clearly 7.2 and 7.3 have the same minor version for all interfaces. Bad!
We forgot between 7.0 and 7.1 as well, so it's at least consistent...
--
Peter Eisentraut peter_e@gmx.net
Peter Eisentraut wrote:
Bruce Momjian writes:
so clearly 7.2 and 7.3 have the same minor version for all interfaces. Bad!
We forgot between 7.0 and 7.1 as well, so it's at least consistent...
Yes, seems we increament on every even-numbered release. ;-)
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
On Wed, 2002-12-04 at 13:11, Bruce Momjian wrote:
Seems I did forget. I always update the minor for a major release, but
when development starts, and I seem to have forgotten for 7.3. Sorry.I will update for 7.4 now. Too late for 7.3 clearly.
Wouldn't that suggest that libpq in 7.4 and 7.3 are *not* binary
compatible? AFAIK that's not the case...
Cheers,
Neil
--
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC
Neil Conway wrote:
On Wed, 2002-12-04 at 13:11, Bruce Momjian wrote:
Seems I did forget. I always update the minor for a major release, but
when development starts, and I seem to have forgotten for 7.3. Sorry.I will update for 7.4 now. Too late for 7.3 clearly.
Wouldn't that suggest that libpq in 7.4 and 7.3 are *not* binary
compatible? AFAIK that's not the case...
I updated the _minor_ version number, which doesn't affect binary
compatibility, I think. It only makes the newer one more visible.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Bruce Momjian writes:
Tom Lane wrote:
Lee Kindness <lkindness@csl.co.uk> writes:
Perhaps the .so name should have been updated for PostgreSQL 7.3?
It should have been. If it wasn't, that was a serious oversight.
Not sure if we should change it in 7.3.1 or not, though; it may be
too late for that. Any thoughts out there?Seems I did forget. I always update the minor for a major release, but
when development starts, and I seem to have forgotten for 7.3. Sorry.
Personally I think automatically updating the version numbers is as
bad as not doing it at all - it misses the point.
The version numbers in shared library filenames denote binary
compatibilty, if the /public/ API changes then the version number
really must be incremented.
If the version increments without any associated API changes then it's
just a PITA for developers and products linking to the PostgreSQL
libraries! It forces recompilation when there is not really a need.
Lee.
Lee Kindness wrote:
Bruce Momjian writes:
Tom Lane wrote:
Lee Kindness <lkindness@csl.co.uk> writes:
Perhaps the .so name should have been updated for PostgreSQL 7.3?
It should have been. If it wasn't, that was a serious oversight.
Not sure if we should change it in 7.3.1 or not, though; it may be
too late for that. Any thoughts out there?Seems I did forget. I always update the minor for a major release, but
when development starts, and I seem to have forgotten for 7.3. Sorry.Personally I think automatically updating the version numbers is as
bad as not doing it at all - it misses the point.The version numbers in shared library filenames denote binary
compatibilty, if the /public/ API changes then the version number
really must be incremented.If the version increments without any associated API changes then it's
just a PITA for developers and products linking to the PostgreSQL
libraries! It forces recompilation when there is not really a need.
It is my understanding that only the major number force recompliation.
We came up with this procedure after quite a bit of discussion. I am
happy to change it, but I need more than one person to tell me that.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian wrote:
I will update for 7.4 now. Too late for 7.3 clearly.
Bruce, why is it too late?
Most (all) will upgrade to 7.3.1 anyway, so it is a chance to get things right.
--
Fernando Nasser
Red Hat - Toronto E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
Fernando Nasser wrote:
Bruce Momjian wrote:
I will update for 7.4 now. Too late for 7.3 clearly.
Bruce, why is it too late?
Most (all) will upgrade to 7.3.1 anyway, so it is a chance to get things right.
Oh. yes. Is it safe to do that?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Bruce Momjian <pgman@candle.pha.pa.us> writes:
Fernando Nasser wrote:
Bruce Momjian wrote:
Bruce, why is it too late?Most (all) will upgrade to 7.3.1 anyway, so it is a chance to get things right.
Oh. yes. Is it safe to do that?
The RPM packagers should probably have a say in this, but I'm leaning
to agree with Fernando. The bulk of our users probably will not update
from 7.2.* to 7.3 before 7.3.1 is out (at least not for production),
so the fact that 7.3 has the wrong library version number won't affect
them. But people will continue to get burnt if we don't fix it for
7.3.1.
It is not real clear to me whether we need a major version bump, rather
than a minor one. We *do* need to signal binary incompatibility. Who
can clarify the rules here?
regards, tom lane
On Thu, Dec 05, 2002 at 03:27:23PM -0500, Tom Lane wrote:
It is not real clear to me whether we need a major version bump, rather
than a minor one. We *do* need to signal binary incompatibility. Who
can clarify the rules here?
One thing I wonder about: should the rules make any distinction between
API incompatibilities and client protocol incompatibilities? For the
former I would imagine one would like to have some "minor" version number
increase whenever features are added and a "major" number be incremented
when changes become incompatible. For the former, one would probably
want to have a similar rule but with a dichotomy between server-side
upgrades and client-side upgrades.
Jeroen
Jeroen T. Vermeulen wrote:
On Thu, Dec 05, 2002 at 03:27:23PM -0500, Tom Lane wrote:
It is not real clear to me whether we need a major version bump, rather
than a minor one. We *do* need to signal binary incompatibility. Who
can clarify the rules here?One thing I wonder about: should the rules make any distinction between
API incompatibilities and client protocol incompatibilities? For the
former I would imagine one would like to have some "minor" version number
increase whenever features are added and a "major" number be incremented
when changes become incompatible. For the former, one would probably
want to have a similar rule but with a dichotomy between server-side
upgrades and client-side upgrades.
Yes, now that I remember, that was the big distinction. One requires a
recompile, the other one doesn't even work with a newer db.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Tom Lane writes:
It is not real clear to me whether we need a major version bump, rather
than a minor one. We *do* need to signal binary incompatibility. Who
can clarify the rules here?
Strictly speaking, it's platform-dependent, but our shared library code
plays a bit of abuse with it. What it comes down to is:
If you change or remove an interface, increment the major version number.
If you add an interface, increment the minor version number. If you did
neither but changed the source code at all, increment the third version
number, if we had one.
To be thoroughly amused, read the libtool source. Grep for 'version_type'.
--
Peter Eisentraut peter_e@gmx.net
Peter Eisentraut wrote:
Tom Lane writes:
It is not real clear to me whether we need a major version bump, rather
than a minor one. We *do* need to signal binary incompatibility. Who
can clarify the rules here?Strictly speaking, it's platform-dependent, but our shared library code
plays a bit of abuse with it. What it comes down to is:If you change or remove an interface, increment the major version number.
If you add an interface, increment the minor version number. If you did
neither but changed the source code at all, increment the third version
number, if we had one.
My take on it is: if you break binary compatibility, which includes
semantic dependencies, then you increment the major version number.
Otherwise you increment the minor version number.
Since the change we're talking about apparently broke binary
compatibility, it calls for a major version number change.
Protocol incompatibility requires a different method of enforcement
altogether. Incrementing the major number of the library isn't going
to do you any good for that (7.2 clients on remote systems won't have
any idea that the libraries on the 7.3 server have changed that much).
All MHO, of course...
--
Kevin Brown kevin@sysexperts.com
This is your .signature virus: < begin 644 .signature (9V]T8VAA(0K0z end >
This is your .signature virus on drugs: <>
Any questions?
OK, seeing that we don't have a third number, do people want me to
increment the interface numbers for 7.3.1, or just wait for the
increment in 7.4?
---------------------------------------------------------------------------
Peter Eisentraut wrote:
Tom Lane writes:
It is not real clear to me whether we need a major version bump, rather
than a minor one. We *do* need to signal binary incompatibility. Who
can clarify the rules here?Strictly speaking, it's platform-dependent, but our shared library code
plays a bit of abuse with it. What it comes down to is:If you change or remove an interface, increment the major version number.
If you add an interface, increment the minor version number. If you did
neither but changed the source code at all, increment the third version
number, if we had one.To be thoroughly amused, read the libtool source. Grep for 'version_type'.
--
Peter Eisentraut peter_e@gmx.net
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
At 06:36 PM 10/12/2002 -0500, Bruce Momjian wrote:
do people want me to
increment the interface numbers for 7.3.1
I'd like it because I have to support & build against multiple versions.
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 03 5330 3172 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/
