Re: Getting to 8.3 beta1

We're so close I can almost taste it ... Here are the open tasks
I can see, does anyone have others?

* Review the one remaining patch from Simon that's on Bruce's patch
queue page
http://momjian.us/cgi-bin/pgpatches
(Everything else on that page is either dealt with, mentioned explicitly
below, or simply a documentation improvement issue, which need not
hold up beta1.)

* Deal with the "#define FRONTEND" issue that Hiroshi Saito is working
on (see "Warning is adjusted of pgbench" thread).

* Decide whether we need to change CSVLOG output to emit virtual XIDs
instead of, or perhaps in addition to, regular XIDs. I'm of the opinion
that this has to happen, but there didn't seem much enthusiasm for it
elsewhere.

* Pending patches for pre-existing bugs in contrib/pgcrypto --- this
doesn't seem like a beta-stopper anyway.

* What are we going to do with contrib/tsearch2? Probably not a beta
stopper either, but it needs to be decided.

* Do we bump the .so major version number for libpq? I think we should
because there are two new exported functions since 8.2, and on at least
some platforms there's nothing else than major number to disambiguate
whether a client needs these or not. Comments?

* Draft release notes --- can't really ship a beta without these,
else beta testers won't know what to test. Traditionally this has
taken a fair amount of time, but I wonder whether we couldn't use
http://developer.postgresql.org/index.php/WhatsNew83
for at least the first cut.

I think we could possibly release 8.3beta1 on Monday, or certainly
next week sometime. And I don't know about anyone else, but I'm
antsy to get this thing out the door ...

regards, tom lane

> * Draft release notes --- can't really ship a beta without these,
> else beta testers won't know what to test. Traditionally this has
> taken a fair amount of time, but I wonder whether we couldn't use
> http://developer.postgresql.org/index.php/WhatsNew83
> for at least the first cut.

Pls, add:
* Indexes (B-Tree and GiST) could be used for IS NULL clause
* User-defined types now could have a type modifiers
* nulls first/last could be specified in CREATE INDEX .. USING btree

--
Teodor Sigaev E-mail: teodor(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/

On Thu, 2007-09-27 at 11:22 -0400, Tom Lane wrote:

> * Review the one remaining patch from Simon that's on Bruce's patch
> queue page
> http://momjian.us/cgi-bin/pgpatches
> (Everything else on that page is either dealt with, mentioned explicitly
> below, or simply a documentation improvement issue, which need not
> hold up beta1.)

Dang, me again eh? :-)

Well, I'm available now and tomorrow to do any further work required.

--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com

On Thursday 27 September 2007 08:22:46 Tom Lane wrote:
> We're so close I can almost taste it ... Here are the open tasks
> I can see, does anyone have others?
>
> * Review the one remaining patch from Simon that's on Bruce's patch
> queue page
> http://momjian.us/cgi-bin/pgpatches
> (Everything else on that page is either dealt with, mentioned explicitly
> below, or simply a documentation improvement issue, which need not
> hold up beta1.)
>
> * Deal with the "#define FRONTEND" issue that Hiroshi Saito is working
> on (see "Warning is adjusted of pgbench" thread).
>
> * Decide whether we need to change CSVLOG output to emit virtual XIDs
> instead of, or perhaps in addition to, regular XIDs. I'm of the opinion
> that this has to happen, but there didn't seem much enthusiasm for it
> elsewhere.

I think it should be both

>
> * Pending patches for pre-existing bugs in contrib/pgcrypto --- this
> doesn't seem like a beta-stopper anyway.
>
> * What are we going to do with contrib/tsearch2? Probably not a beta
> stopper either, but it needs to be decided.
>
> * Do we bump the .so major version number for libpq? I think we should
> because there are two new exported functions since 8.2, and on at least
> some platforms there's nothing else than major number to disambiguate
> whether a client needs these or not. Comments?

+1 on the bump

>
> * Draft release notes --- can't really ship a beta without these,
> else beta testers won't know what to test. Traditionally this has
> taken a fair amount of time, but I wonder whether we couldn't use
> http://developer.postgresql.org/index.php/WhatsNew83
> for at least the first cut.
>
> I think we could possibly release 8.3beta1 on Monday, or certainly
> next week sometime. And I don't know about anyone else, but I'm
> antsy to get this thing out the door ...
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly

--

Darcy Buskermolen
The PostgreSQL company, Command Prompt Inc.
http://www.commandprompt.com/

Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> Dang, me again eh? :-)
> Well, I'm available now and tomorrow to do any further work required.

Looking back at your original discussion of the bug,
http://archives.postgresql.org/pgsql-hackers/2007-06/msg00234.php
I'm wondering why you chose option #3 rather than option #4?
I still find the proposed patch a bit crufty.

regards, tom lane

I wrote:
> Looking back at your original discussion of the bug,
> http://archives.postgresql.org/pgsql-hackers/2007-06/msg00234.php
> I'm wondering why you chose option #3 rather than option #4?
> I still find the proposed patch a bit crufty.

In particular, it seems like a patch per #4 would be a one-liner:

*** src/backend/access/transam/xlog.c.orig Wed Sep 26 18:36:30 2007
--- src/backend/access/transam/xlog.c Thu Sep 27 12:20:56 2007
***************
*** 5092,5101 ****
*
* If we stopped short of the end of WAL during recovery, then we are
* generating a new timeline and must assign it a unique new ID.
* Otherwise, we can just extend the timeline we were in when we ran out
* of WAL.
*/
! if (needNewTimeLine)
{
ThisTimeLineID = findNewestTimeLine(recoveryTargetTLI) + 1;
ereport(LOG,
--- 5092,5103 ----
*
* If we stopped short of the end of WAL during recovery, then we are
* generating a new timeline and must assign it a unique new ID.
+ * We also force a new timeline when recovering from an archive, to avoid
+ * problems with trying to overwrite existing archived segments.
* Otherwise, we can just extend the timeline we were in when we ran out
* of WAL.
*/
! if (needNewTimeLine || (InArchiveRecovery && XLogArchivingActive()))
{
ThisTimeLineID = findNewestTimeLine(recoveryTargetTLI) + 1;
ereport(LOG,

though I admit I've not tested this. The comments in
exitArchiveRecovery probably need adjustment too --- re-reading them,
it seems obvious that the current approach is broken by design, because
it *must* lead to an attempt to overwrite a previously archived version
of the last segment.

regards, tom lane

Tom Lane wrote:
> * Decide whether we need to change CSVLOG output to emit virtual XIDs
> instead of, or perhaps in addition to, regular XIDs. I'm of the opinion
> that this has to happen, but there didn't seem much enthusiasm for it
> elsewhere.
>

Given we have both in log_line_prefix I'm inclined to say we should do both.

On other matters, I think it has been sufficiently established that the
regression issues with ECPG/MSVC have nothing to do with the build or
vcregress scripts, so I am going to go ahead and commit my changes for
those ahead of beta.

cheers

andrew

On Thu, 2007-09-27 at 12:07 -0400, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> > Dang, me again eh? :-)
> > Well, I'm available now and tomorrow to do any further work required.
>
> Looking back at your original discussion of the bug,
> http://archives.postgresql.org/pgsql-hackers/2007-06/msg00234.php
> I'm wondering why you chose option #3 rather than option #4?

IIRC you rejected #4 here
http://archives.postgresql.org/pgsql-admin/2007-03/msg00237.php
I was raising it again 'cos I thought it sensible, and still do.

#4 is easy enough to implement, so I worked on #3 so we had a choice.

> I still find the proposed patch a bit crufty.

Your coding is always neater than mine, so we need not debate my
cruftiness. There are two parts to the patch as submitted; IIRC the
shorter chunk *may* be cosmetic only - though its too far back for me to
recall with precision.

The main issue is that we send *back* to the archive a file that we just
got from it, which is always wrong. Stopping it from doing that in a
direct manner seems much neater to me. #4 solves another problem
(mentioned in the thread you quote on Admin), so I want that, but I
dislike the circuitous manner in which it solves this problem. We'd need
to document carefully to avoid a future bug there.

I would prefer #3 and #4 together...

--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com

Tom Lane wrote:
> * Do we bump the .so major version number for libpq? I think we should
> because there are two new exported functions since 8.2, and on at least
> some platforms there's nothing else than major number to disambiguate
> whether a client needs these or not. Comments?

I'm not very familiar with library versioning, but the modern solution
is to use symbol versioning. In that scheme, a backwards-compatible
change, like adding new functions, requires a bump of the minor version
number only. I believe all major modern platforms supports symbol
versioning.

At runtime, the dynamic linker checks that the major version matches the
one the appliction is compiled with, and that the version number on each
symbol is the same or newer than the one the application was compiled with.

I don't know what's required from the build system to support that, but
I can find out if no-one else volunteers.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

On Thu, 2007-09-27 at 12:26 -0400, Tom Lane wrote:
> I wrote:
> > Looking back at your original discussion of the bug,
> > http://archives.postgresql.org/pgsql-hackers/2007-06/msg00234.php
> > I'm wondering why you chose option #3 rather than option #4?
> > I still find the proposed patch a bit crufty.
>
> In particular, it seems like a patch per #4 would be a one-liner:

Yes, thats my understanding too.

--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com

Andrew Dunstan <ad-ags(at)dunslane(dot)net> writes:
> Tom Lane wrote:
>> * Decide whether we need to change CSVLOG output to emit virtual XIDs
>> instead of, or perhaps in addition to, regular XIDs. I'm of the opinion
>> that this has to happen, but there didn't seem much enthusiasm for it
>> elsewhere.

> Given we have both in log_line_prefix I'm inclined to say we should do both.

Works for me. Do you want to fix it or shall I?

> On other matters, I think it has been sufficiently established that the
> regression issues with ECPG/MSVC have nothing to do with the build or
> vcregress scripts, so I am going to go ahead and commit my changes for
> those ahead of beta.

IIUC, that won't break buildfarm results because the MSVC critters are
skipping the ecpg tests at present anyway, right? If so, +1. We can
work out how to fix the ecpg results during beta.

regards, tom lane

Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
> Tom Lane wrote:
>> * Do we bump the .so major version number for libpq?

> I'm not very familiar with library versioning, but the modern solution
> is to use symbol versioning. In that scheme, a backwards-compatible
> change, like adding new functions, requires a bump of the minor version
> number only. I believe all major modern platforms supports symbol
> versioning.

Yeah, but we are still supporting some not-so-modern platforms. In any
case, to go this route we would have to figure out how to make symbol
versioning work on *every* supported platform, not only the easy ones.
That might be a good long-term goal but I don't want to buy into making
it happen for 8.3.

regards, tom lane

On Thu, 2007-09-27 at 12:26 -0400, Tom Lane wrote:
> I wrote:
> > Looking back at your original discussion of the bug,
> > http://archives.postgresql.org/pgsql-hackers/2007-06/msg00234.php
> > I'm wondering why you chose option #3 rather than option #4?
> > I still find the proposed patch a bit crufty.
>
> In particular, it seems like a patch per #4 would be a one-liner:
>
> *** src/backend/access/transam/xlog.c.orig Wed Sep 26 18:36:30 2007
> --- src/backend/access/transam/xlog.c Thu Sep 27 12:20:56 2007
> ***************
> *** 5092,5101 ****
> *
> * If we stopped short of the end of WAL during recovery, then we are
> * generating a new timeline and must assign it a unique new ID.
> * Otherwise, we can just extend the timeline we were in when we ran out
> * of WAL.
> */
> ! if (needNewTimeLine)
> {
> ThisTimeLineID = findNewestTimeLine(recoveryTargetTLI) + 1;
> ereport(LOG,
> --- 5092,5103 ----
> *
> * If we stopped short of the end of WAL during recovery, then we are
> * generating a new timeline and must assign it a unique new ID.
> + * We also force a new timeline when recovering from an archive, to avoid
> + * problems with trying to overwrite existing archived segments.
> * Otherwise, we can just extend the timeline we were in when we ran out
> * of WAL.
> */
> ! if (needNewTimeLine || (InArchiveRecovery && XLogArchivingActive()))
> {
> ThisTimeLineID = findNewestTimeLine(recoveryTargetTLI) + 1;
> ereport(LOG,

AFAICS the correct test would be

if (InArchiveRecovery)

since needNewTimeLine can only be true iff InArchiveRecovery is true.

It's often a good idea to disable archive_mode when doing a recovery to
avoid trying to send files to the same archive as the primary, which
would then also fail. So requiring XLogArchivingActive() also may not be
desirable.

--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com

Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> On Thu, 2007-09-27 at 12:26 -0400, Tom Lane wrote:
>> In particular, it seems like a patch per #4 would be a one-liner:

> Yes, thats my understanding too.

Do you have time to test that and see if it actually solves the problem?
Also, I'm not entirely sure how far back the patch would work; I seem to
recall that we've changed some things in that area ...

regards, tom lane

On Thu, 2007-09-27 at 12:45 -0400, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> > On Thu, 2007-09-27 at 12:26 -0400, Tom Lane wrote:
> >> In particular, it seems like a patch per #4 would be a one-liner:
>
> > Yes, thats my understanding too.
>
> Do you have time to test that and see if it actually solves the problem?
> Also, I'm not entirely sure how far back the patch would work; I seem to
> recall that we've changed some things in that area ...

Yes, but I won't be finished until tomorrow.

--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com

Tom Lane wrote:
> Andrew Dunstan <ad-ags(at)dunslane(dot)net> writes:
>
>> Tom Lane wrote:
>>
>>> * Decide whether we need to change CSVLOG output to emit virtual XIDs
>>> instead of, or perhaps in addition to, regular XIDs. I'm of the opinion
>>> that this has to happen, but there didn't seem much enthusiasm for it
>>> elsewhere.
>>>
>
>
>> Given we have both in log_line_prefix I'm inclined to say we should do both.
>>
>
> Works for me. Do you want to fix it or shall I?
>
>

If you have a chance please do it - I'm slightly snowed under. It would
probably be Sunday before I could look at it.

cheers

andrew

Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> AFAICS the correct test would be
> if (InArchiveRecovery)
> since needNewTimeLine can only be true iff InArchiveRecovery is true.

> It's often a good idea to disable archive_mode when doing a recovery to
> avoid trying to send files to the same archive as the primary, which
> would then also fail. So requiring XLogArchivingActive() also may not be
> desirable.

Well, that I think is exactly the core of the issue: the "input" archive
area might or might not be the same as the "output" one. If they're
different then this isn't a critical problem; but we have no good way
to know that.

But your simplification may be a good idea anyway --- the fewer
behaviors to think about, the better.

Anyway, if you can test this tomorrow that'll be great. I have enough
other things to do today ...

regards, tom lane

On Thu, Sep 27, 2007 at 05:39:11PM +0100, Heikki Linnakangas wrote:
> I'm not very familiar with library versioning, but the modern solution
> is to use symbol versioning. In that scheme, a backwards-compatible
> change, like adding new functions, requires a bump of the minor version
> number only. I believe all major modern platforms supports symbol
> versioning.

The original patch for controlling the export list on Linux included
support for symbol versioning. Eventually a version of the export.list
control was committed, but without the versioning (it was rejected for
some reason, don't remember why).

In any case, to add it now for linux would be a one-line change.

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> The original patch for controlling the export list on Linux included
> support for symbol versioning. Eventually a version of the export.list
> control was committed, but without the versioning (it was rejected for
> some reason, don't remember why).

My recollection is that it didn't work on older Linuxen.

A lot of this would come down to "are we willing to discontinue support
for platforms that don't have symbol versioning"? Without some legwork
to find out what that actually means, it's premature to try to make a
decision.

Anyway I think this is not 8.3 material; it's something to tackle during
a fresh development cycle.

regards, tom lane

On Thu, Sep 27, 2007 at 01:07:33PM -0400, Tom Lane wrote:
> Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> > The original patch for controlling the export list on Linux included
> > support for symbol versioning. Eventually a version of the export.list
> > control was committed, but without the versioning (it was rejected for
> > some reason, don't remember why).
>
> My recollection is that it didn't work on older Linuxen.

Near as I can tell, glibc has been using symbol versioning for nearly
10 years.

http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/NEWS.diff?r1=1.24&r2=1.25&cvsroot=glibc&f=h

So the chance that there are linux systems out there not supporting it
is fairly slim.

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

* Heikki Linnakangas (heikki(at)enterprisedb(dot)com) wrote:
> Tom Lane wrote:
> > * Do we bump the .so major version number for libpq? I think we should
> > because there are two new exported functions since 8.2, and on at least
> > some platforms there's nothing else than major number to disambiguate
> > whether a client needs these or not. Comments?
>
> I'm not very familiar with library versioning, but the modern solution
> is to use symbol versioning. In that scheme, a backwards-compatible
> change, like adding new functions, requires a bump of the minor version
> number only. I believe all major modern platforms supports symbol
> versioning.

You're kind of half-right... The 'modern' solution is symbol
versioning, but it's certainly not required. A backwards-compatible
change is usually a minor revision bump so that utilities which use the
new functions know that they need a more recent version to use it, while
old utilities can continue to use the interfaces in place. It should
*not* change the soname. Systems do not need symbol versioning support
to handle this properly. Stictly speaking, you don't have to change
anything.

The new library will work for old binaries, that's the primary concern
and if functions are only added there's no problem. If you're concerned
about new binaries with an old library then bump the minor version. It
won't stop them from attempting to link but it's a signal to packagers
to update their dependencies accordingly.

Few projects have moved to symbol versioning, unfortunately. glibc is
the big user of it and they do a good job of it in general. This allows
in-place upgrades of glibc and supporting multiple versions of glibc
symbols being exported at once. It also means that multiple glibc's can
be linked in to a running binary at once.

Bumping the soname is an indication of a binary-incompatible change and
means that old binaries *can't* link against the new library, and so
everything has to be recompiled. Please don't do that unless it really
is a binary-incompatible change because it's alot of extra work for
packagers to deal with all of their reverse dependencies and getting
everyone to recompile.

Thanks,

Stephen

teodor(at)sigaev(dot)ru (Teodor Sigaev) writes:
>> * Draft release notes --- can't really ship a beta without these,
>> else beta testers won't know what to test. Traditionally this has
>> taken a fair amount of time, but I wonder whether we couldn't use
>> http://developer.postgresql.org/index.php/WhatsNew83
>> for at least the first cut.
>
> Pls, add:
> * Indexes (B-Tree and GiST) could be used for IS NULL clause
> * User-defined types now could have a type modifiers
> * nulls first/last could be specified in CREATE INDEX .. USING btree

The third item was already on the list; I have added the other two,
but don't have much explanation for them...
--
let name="cbbrowne" and tld="cbbrowne.com" in name ^ "@" ^ tld;;
http://www3.sympatico.ca/cbbrowne/multiplexor.html
"In man-machine symbiosis, it is man who must adjust: The machines
can't." -- Alan J. Perlis

Stephen Frost <sfrost(at)snowman(dot)net> writes:
>> Tom Lane wrote:
>>> * Do we bump the .so major version number for libpq? I think we should
>>> because there are two new exported functions since 8.2, and on at least
>>> some platforms there's nothing else than major number to disambiguate
>>> whether a client needs these or not. Comments?

> Bumping the soname is an indication of a binary-incompatible change and
> means that old binaries *can't* link against the new library, and so
> everything has to be recompiled. Please don't do that unless it really
> is a binary-incompatible change because it's alot of extra work for
> packagers to deal with all of their reverse dependencies and getting
> everyone to recompile.

It's not only a question of whether old binaries can use the newer
library; it's a question of whether a package's dependencies correctly
show that it needs the newer library (if it does). Without this,
dependency-solving update systems like yum, apt, etc may fail to install
prerequisite updates.

If we can skip the compatibility-package pushup this time around,
I'll be as happy as anyone. But I'm worried about getting into the
kind of mess we had in 8.0, where we decided *after* release that
we needed a soname bump :-(

Anyone on -packagers want to weigh in on this?

regards, tom lane

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > Bumping the soname is an indication of a binary-incompatible change and
> > means that old binaries *can't* link against the new library, and so
> > everything has to be recompiled. Please don't do that unless it really
> > is a binary-incompatible change because it's alot of extra work for
> > packagers to deal with all of their reverse dependencies and getting
> > everyone to recompile.
>
> It's not only a question of whether old binaries can use the newer
> library; it's a question of whether a package's dependencies correctly
> show that it needs the newer library (if it does). Without this,
> dependency-solving update systems like yum, apt, etc may fail to install
> prerequisite updates.

Right, the minor version bump tells the maintainer (and/or if he/she
follows the dev lists/release notes) to adjust the dependencies. The
maintainer would then adjust, at least on Debian, the shlibs files when
building the new library and packages using dh_makeshlibs, dh_shlibdeps,
dpkg-shlibdeps, etc would pick up on the new dependency.

The new version of the library will be installed whenever it's scheduled
to be upgraded, or immediately if new binaries that have been compiled
against it are also being installed.

Technically, that's strictly harsher than it has to be, but if you're
recompiling you might as well require the latest ABI even if you don't
use the new functions. Figuring out if the new functions are
being used or not so that you could perhaps allow for use of an older
library is probably more trouble than it's worth and would require much
more complicated dependencies that would buy very little...

> If we can skip the compatibility-package pushup this time around,
> I'll be as happy as anyone. But I'm worried about getting into the
> kind of mess we had in 8.0, where we decided *after* release that
> we needed a soname bump :-(

I agree, that's certainly quite ugly, but if we've only added functions
and not changed existing function ABIs at all then I can't see any
reason why that would happen here. We're quite confident there have
been only new funcs, right? Would it be possible to run the regression
tests with an older binary and the libraries from HEAD? I would think
that would be a good test if we're unsure.

Of course, that would be problematic if the PG binaries use unexported
symbols in the libraries which changed between the releases (that's
rather nasty to do, imv, but it certainly wouldn't be the first time
I've seen it done in a project). We could test some non-PG binaries in
that case, of course, but it wouldn't be as good a test.

Thanks,

Stephen

Tom Lane wrote:

>Stephen Frost <sfrost(at)snowman(dot)net> writes:
>
>
>>>Tom Lane wrote:
>>>
>>>
>>>>* Do we bump the .so major version number for libpq? I think we should
>>>>because there are two new exported functions since 8.2, and on at least
>>>>some platforms there's nothing else than major number to disambiguate
>>>>whether a client needs these or not. Comments?
>>>>
>>>>
>
>
>
>>Bumping the soname is an indication of a binary-incompatible change and
>>means that old binaries *can't* link against the new library, and so
>>everything has to be recompiled. Please don't do that unless it really
>>is a binary-incompatible change because it's alot of extra work for
>>packagers to deal with all of their reverse dependencies and getting
>>everyone to recompile.
>>
>>
>
>It's not only a question of whether old binaries can use the newer
>library; it's a question of whether a package's dependencies correctly
>show that it needs the newer library (if it does). Without this,
>dependency-solving update systems like yum, apt, etc may fail to install
>prerequisite updates.
>
>If we can skip the compatibility-package pushup this time around,
>I'll be as happy as anyone. But I'm worried about getting into the
>kind of mess we had in 8.0, where we decided *after* release that
>we needed a soname bump :-(
>
>Anyone on -packagers want to weigh in on this?
>
>

I'm for bumbing. Because if we use same number it also means that new
binary will able to use old library. But if there are two new functions
number must be increased. Standard practice how ELF loader works is
following:

Each library could have tree numbers libxxx-X.Y.Z. Loader/Linker ignores
Z number. It means any binaries can be linked e.g. with X.Y.Z+1 or
X.Y.Z-1. This is used for bugfixing. Middle number Y means that binaries
which requires Y can also use Y+1 (and linker takes it), but not Y-1. It
is used for adding new thing into interface - backward compatible.
Change in major number X means it is not backward compatible libraries.

More information you can get there:
http://www.iecc.com/linker/

In PostgreSQL perspective, we use only major number. We can increase
main number (X) or best way is add Y and keep major number same. But I
don't know if it is possible in current infrastructure and if it will
work everywhere.

Zdenek

Tom Lane wrote:

>We're so close I can almost taste it ... Here are the open tasks
>I can see, does anyone have others?
>
>
>
>

>* Pending patches for pre-existing bugs in contrib/pgcrypto --- this
>doesn't seem like a beta-stopper anyway.
>
>

I agree It is not show stooper for beta. In emergency case patch should
be split to two separate patches. One is easy and fix core dump problem.
Second part is more complicated and Marko works on adjustment. But I
don't think that it is necessary for beta.

Zdenek

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tom Lane wrote:
> We're so close I can almost taste it ... Here are the open tasks
> I can see, does anyone have others?
>
> * What are we going to do with contrib/tsearch2? Probably not a beta
> stopper either, but it needs to be decided.

IMO, we loose contrib/tsearch2. I think it will be confusing and cause
problems to have both.

>
> I think we could possibly release 8.3beta1 on Monday, or certainly
> next week sometime. And I don't know about anyone else, but I'm
> antsy to get this thing out the door ...

+1

Sincerely,

Joshua D. Drake

>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>

- --

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240
PostgreSQL solutions since 1997 http://www.commandprompt.com/
UNIQUE NOT NULL
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG/CgVATb/zqfZUUQRAo2ZAJ98mVUJSrnnhxsI7ScnFO0sXHUzXQCeOuph
FllSKn/XvdWfjuvxNF9IfEw=
=lLk1
-----END PGP SIGNATURE-----

* Zdenek(dot)Kotala(at)Sun(dot)COM (Zdenek(dot)Kotala(at)Sun(dot)COM) wrote:
> I'm for bumbing. Because if we use same number it also means that new
> binary will able to use old library. But if there are two new functions
> number must be increased. Standard practice how ELF loader works is
> following:
>
> Each library could have tree numbers libxxx-X.Y.Z. Loader/Linker ignores Z
> number. It means any binaries can be linked e.g. with X.Y.Z+1 or X.Y.Z-1.
> This is used for bugfixing. Middle number Y means that binaries which
> requires Y can also use Y+1 (and linker takes it), but not Y-1. It is used
> for adding new thing into interface - backward compatible. Change in major
> number X means it is not backward compatible libraries.

Right, so bump the minor and leave the major (and the overall 'soname')
the same.

> In PostgreSQL perspective, we use only major number. We can increase main
> number (X) or best way is add Y and keep major number same. But I don't
> know if it is possible in current infrastructure and if it will work
> everywhere.

I'm confused by this. I see both in Makefile.shlib and on my system
that we have a minor version so I don't entirely follow when you say "we
use only major number". In practice, at least on Debian, all that
really matters is that the maintainer update the Debian 'shlibs' for the
library so that new compilations depend on the newer version. He can
gather that needs to be done through a number of different ways, but
bumping the minor version is a common and sensible way in general.

Bumping the major version forces recompilation for anything which
depends on the library and is alot of wasted effort when it's
unnecessary. It's not sensible for individual distros to change the
soname either though since that would cause all kinds of cross-distro
issues and confusion. It really needs to be handled upstream, and
handled correctly.

Thanks,

Stephen

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Stephen Frost <sfrost(at)snowman(dot)net> writes:
>>> Tom Lane wrote:
>>>> * Do we bump the .so major version number for libpq? I think we should
>>>> because there are two new exported functions since 8.2, and on at least
>>>> some platforms there's nothing else than major number to disambiguate
>>>> whether a client needs these or not. Comments?
>
>> Bumping the soname is an indication of a binary-incompatible change and
>> means that old binaries *can't* link against the new library, and so
>> everything has to be recompiled. Please don't do that unless it really
>> is a binary-incompatible change because it's alot of extra work for
>> packagers to deal with all of their reverse dependencies and getting
>> everyone to recompile.
>
> It's not only a question of whether old binaries can use the newer
> library; it's a question of whether a package's dependencies correctly
> show that it needs the newer library (if it does). Without this,
> dependency-solving update systems like yum, apt, etc may fail to install
> prerequisite updates.

Well either way would work for apt. It notices the version of the library
installed when you build a package and records that version as the dependency
of the package.

If you don't bump then it means you can only have one version of libpq
installed at the same time. When installing the new libpq from the 8.3
packages all existing packages would immediately start using it. Any packages
built while the new library was installed would claim to depend on the new
version (unless the packager overrode the automatic shlib dependency).

If you do bump then it means you can keep both copies of the library
installed. All old packages would continue to use the old library until
they're rebuilt. If they're rebuilt when the new package is installed then
they'll start depending on the new version.

I'm not sure how yum works, does it not handle this case?

Separately are we really sure the shared libraries are completely binary
compatible? Didn't the password authentication do something tricky? If you
have existing binaries there's no case where they'll break if you swap the
shared library out from under them?

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

* Gregory Stark (stark(at)enterprisedb(dot)com) wrote:
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> > Stephen Frost <sfrost(at)snowman(dot)net> writes:
> >> Bumping the soname is an indication of a binary-incompatible change and
> >> means that old binaries *can't* link against the new library, and so
> >> everything has to be recompiled. Please don't do that unless it really
> >> is a binary-incompatible change because it's alot of extra work for
> >> packagers to deal with all of their reverse dependencies and getting
> >> everyone to recompile.
> >
> > It's not only a question of whether old binaries can use the newer
> > library; it's a question of whether a package's dependencies correctly
> > show that it needs the newer library (if it does). Without this,
> > dependency-solving update systems like yum, apt, etc may fail to install
> > prerequisite updates.
>
> Well either way would work for apt. It notices the version of the library
> installed when you build a package and records that version as the dependency
> of the package.

More specifically, it records the "shlibs" of the library into the
dependency of the package being built. That is *not* the same as the
exact version of the particular library being being against. The
"shlibs" shouldn't ever be *higher* than the version of the library, but
it can, and often is, *lower*.

> If you don't bump then it means you can only have one version of libpq
> installed at the same time. When installing the new libpq from the 8.3
> packages all existing packages would immediately start using it. Any packages
> built while the new library was installed would claim to depend on the new
> version (unless the packager overrode the automatic shlib dependency).

Right, assuming that we're talking about a case where there was some
backward-compatible change in the ABI (functions were added), as in this
case.

> If you do bump then it means you can keep both copies of the library
> installed. All old packages would continue to use the old library until
> they're rebuilt. If they're rebuilt when the new package is installed then
> they'll start depending on the new version.

This really is rather ugly when you have to deal with it though. It
means that packages *have* to be rebuilt to use the new library and
it makes it a huge pain to get rid of the old library. It also puts you
in the ugly and annoying situation that both libraries can end up linked
into the same running binary.

> I'm not sure how yum works, does it not handle this case?

Yeah, I'm not familiar with non-Debian systems, though the major/minor
approach to libraries is used on most systems I've had occation to work
with. Though, honestly, on the commercial (Sun, Irix, HPUX, etc)
systems I've run into, the admins tend to ignore the whole issue
entirely and just recompile/upgrade everything anyway. It's been a
while tho, so perhaps things have changed.

> Separately are we really sure the shared libraries are completely binary
> compatible? Didn't the password authentication do something tricky? If you
> have existing binaries there's no case where they'll break if you swap the
> shared library out from under them?

This is where I was suggesting doing something like running the
regression tests using old client libraries linked against the new
library. If there's a binary-incompatible change then the path is
clear. If the regression tests work fine then I'd feel comfortable
just bumping the minor version and leaving the real 'soname' alone.

Thanks,

Stephen

Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> If you do bump then it means you can keep both copies of the library
> installed.

I looked back into the archives and found that both of our recent libpq
major version bumps were due to unintentional ABI breaks, in the form of
removing not-officially-exported functions that were actually being
depended on by our other client-side code:
http://archives.postgresql.org/pgsql-hackers/2005-02/msg00059.php
http://archives.postgresql.org/pgsql-patches/2006-04/msg00240.php

After the second one of those we finally put in exports.txt filtering,
and I think we can be reasonably confident that it won't happen again
*on platforms where the export filtering works*. If we're willing to
assume that those are the only platforms where concurrent installation
of different versions is well-supported, then we can probably get away
without a major version bump now.

The case that most people care about is being able to update libpq
without recompiling dependent applications, and just adding new export
symbols shouldn't be an issue for that. Although I was worried about
packagers being unhappy about two releases with the same soname, I
cannot find any evidence in the archives that we have ever bumped
the major number without an ABI-break reason. (The previous two bumps
were for intentional API changes, btw.)

So personally I withdraw my concern about this --- the existing "5.1"
numbering should be OK. It's a sore spot because we have blown it three
times running on not bumping the major number when there was a need to,
but now we have some defense against being blindsided the way we were
the last two times; and the time before was just plain failure to
consider whether we needed to bump the major version:
http://archives.postgresql.org/pgsql-hackers/2002-12/msg00213.php

regards, tom lane

> We're so close I can almost taste it ... Here are the open tasks
> I can see, does anyone have others?
>
> * Review the one remaining patch from Simon that's on Bruce's patch
> queue page
> http://momjian.us/cgi-bin/pgpatches
> (Everything else on that page is either dealt with, mentioned explicitly
> below, or simply a documentation improvement issue, which need not
> hold up beta1.)
>
> * Deal with the "#define FRONTEND" issue that Hiroshi Saito is working
> on (see "Warning is adjusted of pgbench" thread).
>
> * Decide whether we need to change CSVLOG output to emit virtual XIDs
> instead of, or perhaps in addition to, regular XIDs. I'm of the opinion
> that this has to happen, but there didn't seem much enthusiasm for it
> elsewhere.
>
> * Pending patches for pre-existing bugs in contrib/pgcrypto --- this
> doesn't seem like a beta-stopper anyway.
>
> * What are we going to do with contrib/tsearch2? Probably not a beta
> stopper either, but it needs to be decided.
>
> * Do we bump the .so major version number for libpq? I think we should
> because there are two new exported functions since 8.2, and on at least
> some platforms there's nothing else than major number to disambiguate
> whether a client needs these or not. Comments?
>
> * Draft release notes --- can't really ship a beta without these,
> else beta testers won't know what to test. Traditionally this has
> taken a fair amount of time, but I wonder whether we couldn't use
> http://developer.postgresql.org/index.php/WhatsNew83
> for at least the first cut.

I see no problem here. However the list looks to miss some 8.3
features (for example JIS2004 support). Also it lacks mentioning the
imcompatibilty with earilier version or removed features.

Since I have to prepare Japanese materials for 8.3 to promote it
anyway, it's ok for me. I have already made presentations about 8.3
last month and this month, and am going to write one or two articles
for some publishers in Japan. I believe 8.3 is one of the greatest
versions since PostgreSQL was born. I would like to promote 8.3's
superiorly as much as possible.

I would like to say thank you to everyone who have been working hard
for 8.3!
--
Tatsuo Ishii
SRA OSS, Inc. Japan

> I think we could possibly release 8.3beta1 on Monday, or certainly
> next week sometime. And I don't know about anyone else, but I'm
> antsy to get this thing out the door ...
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly

Tatsuo Ishii <ishii(at)postgresql(dot)org> writes:
>> * Draft release notes --- can't really ship a beta without these,
>> else beta testers won't know what to test. Traditionally this has
>> taken a fair amount of time, but I wonder whether we couldn't use
>> http://developer.postgresql.org/index.php/WhatsNew83
>> for at least the first cut.

> I see no problem here. However the list looks to miss some 8.3
> features (for example JIS2004 support). Also it lacks mentioning the
> imcompatibilty with earilier version or removed features.

Anyone want to add those points to the wiki page?

Also, I spent a dreary two or three hours this afternoon examining the
CVS commit logs since 8.3 branched. After cutting out docs-only
commits, issues that were also back-patched (and hence are release-noted
already), bug fixes to new-in-8.3 code, etc, there were still nearly 300
messages that seem interesting for release-note purposes. We've been
busy.

I tried to post that info to pgsql-docs but it broke the list's message
size limits (even gzipped, it's about 90K). I'd be happy to send it
off-list to anyone who is interested in trying to distill some
preliminary release notes.

regards, tom lane

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tom Lane wrote:
> Tatsuo Ishii <ishii(at)postgresql(dot)org> writes:

> Also, I spent a dreary two or three hours this afternoon examining the
> CVS commit logs since 8.3 branched. After cutting out docs-only
> commits, issues that were also back-patched (and hence are release-noted
> already), bug fixes to new-in-8.3 code, etc, there were still nearly 300
> messages that seem interesting for release-note purposes. We've been
> busy.
>
> I tried to post that info to pgsql-docs but it broke the list's message
> size limits (even gzipped, it's about 90K). I'd be happy to send it
> off-list to anyone who is interested in trying to distill some
> preliminary release notes.

I would be happy to give it a shot.

Joshua D. Drake

>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>

- --

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240
PostgreSQL solutions since 1997 http://www.commandprompt.com/
UNIQUE NOT NULL
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG/HadATb/zqfZUUQRAuhfAJ0chJp3zIWBh/TZhMcrtdW/v9oByQCZAXo1
PahgKEFqgJJovdcVem0Kjl8=
=cMXa
-----END PGP SIGNATURE-----

"Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
> Tom Lane wrote:
>> * What are we going to do with contrib/tsearch2? Probably not a beta
>> stopper either, but it needs to be decided.

> IMO, we loose contrib/tsearch2. I think it will be confusing and cause
> problems to have both.

Certainly we aren't going to ship it as-is. What I was wondering was
whether there was any use in creating a backwards-compatibility package
for current users of tsearch2 --- and if so whether anyone felt like
making that happen. If not, we'll just "cvs remove" the thing before
8.3 final release; but I'm throwing the point out as something that
somebody might want to work on before final.

regards, tom lane

> > IMO, we loose contrib/tsearch2. I think it will be confusing and cause
> > problems to have both.
>
> Certainly we aren't going to ship it as-is. What I was wondering was
> whether there was any use in creating a backwards-compatibility package
> for current users of tsearch2 --- and if so whether anyone felt like
> making that happen. If not, we'll just "cvs remove" the thing before
> 8.3 final release; but I'm throwing the point out as something that
> somebody might want to work on before final.
>
Hello,

next week I can work on it. I expect so compatibility functions will
be only sql wrappers

Regards
Pavel Stehule

> > * Do we bump the .so major version number for libpq? I think we
should
> > because there are two new exported functions since 8.2, and on at
least
> > some platforms there's nothing else than major number to
disambiguate
> > whether a client needs these or not. Comments?

-1. You don't bump major if the old api can be used 1:1 with the new
lib.
New functions is not a reason for a major bump.
The major version business is to protect you from ruining currently
running
(old) programs, not from using a too old lib with newly compiled
programs.

Andreas

"Stephen Frost" <sfrost(at)snowman(dot)net> writes:

> This is where I was suggesting doing something like running the
> regression tests using old client libraries linked against the new
> library. If there's a binary-incompatible change then the path is
> clear. If the regression tests work fine then I'd feel comfortable
> just bumping the minor version and leaving the real 'soname' alone.

Unfortunately the regression tests don't really test the library interface.
They test that various forms of SQL work but all with a single client and a
single form of authentication.

What we want to know is that things like pgadmin can connect properly to
either 8.3, 8.2, and even 8.1 using the new libraries regardless of how the
server authentication is configured. Do they work correctly if the server
tries to do password authentication, ident, kerberos, etc.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

Gregory Stark wrote:
> What we want to know is that things like pgadmin can connect properly to
> either 8.3, 8.2, and even 8.1 using the new libraries regardless of how the
> server authentication is configured. Do they work correctly if the server
> tries to do password authentication, ident, kerberos, etc.

That's a matter of protocol-compatibility, and that's not the issue
here. We're talking about *ABI* compatibility. In a nutshell, if you
have a an program that's compiled with 8.2 libpq-library, will it work
when linked to 8.3 library at runtime? And if you have a program
compiled with 8.3 library, does it work with a 8.2 library?

But yeah, the regression tests won't help much with that. I suppose you
could try to use an 8.2 psql with an 8.3 library and see if it works,
but I don't know how much of the library interface psql exercises.

I think it's easier and more reliable to just go through the commit logs
for libpq, and see if anything has changed. Even that isn't bullet-proof
though. For example, if there's an incompatible change to a struct or a
typedef that's used as a function parameter, that breaks binary
compatibility as well.

In the future, we should try to keep this in mind during the development
cycle, and bump the minor version number the first time a
backwards-compatible change, like adding a new function, is made, and
bump the major version number the first time an incompatible change is
made. Like we do for catalog version, except that we only want to bump
the libpq version number once per release. (though we do sometimes
forget to bump the catalog version number as well)

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

On 9/27/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> * Draft release notes --- can't really ship a beta without these,
> else beta testers won't know what to test. Traditionally this has
> taken a fair amount of time, but I wonder whether we couldn't use
> http://developer.postgresql.org/index.php/WhatsNew83
> for at least the first cut.

I've modified XML part of wiki page:

XML Support
* This new data type (XML) validates input for well-formedness and
has a set of type-safe operations.
* SQL/XML publishing functions, per SQL:2003
* xpath() function for XPath 1.0 expressions evaluation (with
Namespaces support)
* Alternative XML export function

--
Best regards,
Nikolay

* Heikki Linnakangas (heikki(at)enterprisedb(dot)com) wrote:
> Gregory Stark wrote:
> > What we want to know is that things like pgadmin can connect properly to
> > either 8.3, 8.2, and even 8.1 using the new libraries regardless of how the
> > server authentication is configured. Do they work correctly if the server
> > tries to do password authentication, ident, kerberos, etc.
>
> That's a matter of protocol-compatibility, and that's not the issue
> here. We're talking about *ABI* compatibility. In a nutshell, if you
> have a an program that's compiled with 8.2 libpq-library, will it work
> when linked to 8.3 library at runtime? And if you have a program
> compiled with 8.3 library, does it work with a 8.2 library?

Right.

> But yeah, the regression tests won't help much with that. I suppose you
> could try to use an 8.2 psql with an 8.3 library and see if it works,
> but I don't know how much of the library interface psql exercises.

Eh, I figure it'll test the more common calls, though I agree that it
doesn't hit every symbol... Perhaps we should look at expanding the
regression tests to try and cover everything exported? That might
require a new binary if we don't want to clutter up psql, but it strikes
me as a pretty decent idea in general.

> I think it's easier and more reliable to just go through the commit logs
> for libpq, and see if anything has changed. Even that isn't bullet-proof
> though. For example, if there's an incompatible change to a struct or a
> typedef that's used as a function parameter, that breaks binary
> compatibility as well.

I agree that this is certainly the best approach, if practical. Another
option would be to just check the symbol list using objdump. Sounds
like Tom already did something similar though by looking through the
exports file.

> In the future, we should try to keep this in mind during the development
> cycle, and bump the minor version number the first time a
> backwards-compatible change, like adding a new function, is made, and
> bump the major version number the first time an incompatible change is
> made. Like we do for catalog version, except that we only want to bump
> the libpq version number once per release. (though we do sometimes
> forget to bump the catalog version number as well)

Agreed.

Thanks,

Stephen

Stephen Frost wrote:
> * Zdenek(dot)Kotala(at)Sun(dot)COM (Zdenek(dot)Kotala(at)Sun(dot)COM) wrote:
>> I'm for bumbing. Because if we use same number it also means that new
>> binary will able to use old library. But if there are two new functions
>> number must be increased. Standard practice how ELF loader works is
>> following:
>>
>> Each library could have tree numbers libxxx-X.Y.Z. Loader/Linker ignores Z
>> number. It means any binaries can be linked e.g. with X.Y.Z+1 or X.Y.Z-1.
>> This is used for bugfixing. Middle number Y means that binaries which
>> requires Y can also use Y+1 (and linker takes it), but not Y-1. It is used
>> for adding new thing into interface - backward compatible. Change in major
>> number X means it is not backward compatible libraries.
>
> Right, so bump the minor and leave the major (and the overall 'soname')
> the same.
>
>> In PostgreSQL perspective, we use only major number. We can increase main
>> number (X) or best way is add Y and keep major number same. But I don't
>> know if it is possible in current infrastructure and if it will work
>> everywhere.
>
> I'm confused by this. I see both in Makefile.shlib and on my system
> that we have a minor version so I don't entirely follow when you say "we
> use only major number".

I'm Sorry for confusion, I overlooked it. You have right. Unfortunately
struct Port has been modified and by my opinion it means we must bump
major version. See
http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/libpq/libpq-be.h.diff?r1=1.62;r2=1.63

Zdenek

Zdenek Kotala wrote:
> I'm Sorry for confusion, I overlooked it. You have right. Unfortunately
> struct Port has been modified and by my opinion it means we must bump
> major version. See
> http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/libpq/libpq-be.h.diff?r1=1.62;r2=1.63

That header file is *not* part of the libpq interface, see the comment
at the beginning of the file. So no major version bump required.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

Zdenek Kotala wrote:
> Stephen Frost wrote:
>> * Zdenek(dot)Kotala(at)Sun(dot)COM (Zdenek(dot)Kotala(at)Sun(dot)COM) wrote:
>>> I'm for bumbing. Because if we use same number it also means that
>>> new binary will able to use old library. But if there are two new
>>> functions number must be increased. Standard practice how ELF loader
>>> works is following:
>>>
>>> Each library could have tree numbers libxxx-X.Y.Z. Loader/Linker
>>> ignores Z number. It means any binaries can be linked e.g. with
>>> X.Y.Z+1 or X.Y.Z-1. This is used for bugfixing. Middle number Y
>>> means that binaries which requires Y can also use Y+1 (and linker
>>> takes it), but not Y-1. It is used for adding new thing into
>>> interface - backward compatible. Change in major number X means it
>>> is not backward compatible libraries.
>>
>> Right, so bump the minor and leave the major (and the overall 'soname')
>> the same.
>>
>>> In PostgreSQL perspective, we use only major number. We can
>>> increase main number (X) or best way is add Y and keep major number
>>> same. But I don't know if it is possible in current infrastructure
>>> and if it will work everywhere.
>>
>> I'm confused by this. I see both in Makefile.shlib and on my system
>> that we have a minor version so I don't entirely follow when you say "we
>> use only major number".
>
> I'm Sorry for confusion, I overlooked it. You have right.
> Unfortunately struct Port has been modified and by my opinion it means
> we must bump major version. See
> http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/libpq/libpq-be.h.diff?r1=1.62;r2=1.63
>
>
>

Uh, that's the backend, not the client lib, no?

cheers

andrew

Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
> Zdenek Kotala wrote:
>> struct Port has been modified and by my opinion it means we must bump
>> major version. See
>> http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/libpq/libpq-be.h.diff?r1=1.62;r2=1.63

> That header file is *not* part of the libpq interface, see the comment
> at the beginning of the file. So no major version bump required.

Right, and even pqcomm.h (to which the comment refers) is material that
is known to libpq (and other implementors of the FE/BE protocol), but is
not exposed to client applications.

This comment in pqcomm.c might be helpful:

* At one time, libpq was shared between frontend and backend, but now
* the backend's "backend/libpq" is quite separate from "interfaces/libpq".
* All that remains is similarities of names to trap the unwary...

The only material that is officially part of the libpq client API is
libpq-fe.h (and postgres_ext.h which it includes). Anyone including
other headers does so at their own risk.

regards, tom lane

Heikki Linnakangas wrote:
> Zdenek Kotala wrote:
>> I'm Sorry for confusion, I overlooked it. You have right. Unfortunately
>> struct Port has been modified and by my opinion it means we must bump
>> major version. See
>> http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/libpq/libpq-be.h.diff?r1=1.62;r2=1.63
>
> That header file is *not* part of the libpq interface, see the comment
> at the beginning of the file. So no major version bump required.
>

I see. You are right. I rechecked also install and this file is not
delivered. OK green for minor bumping.

Zdenek

On Thu, 2007-09-27 at 13:01 -0400, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> > AFAICS the correct test would be
> > if (InArchiveRecovery)
> > since needNewTimeLine can only be true iff InArchiveRecovery is true.
>
> > It's often a good idea to disable archive_mode when doing a recovery to
> > avoid trying to send files to the same archive as the primary, which
> > would then also fail. So requiring XLogArchivingActive() also may not be
> > desirable.
>
> Well, that I think is exactly the core of the issue: the "input" archive
> area might or might not be the same as the "output" one. If they're
> different then this isn't a critical problem; but we have no good way
> to know that.
>
> But your simplification may be a good idea anyway --- the fewer
> behaviors to think about, the better.

Amen to that.

> Anyway, if you can test this tomorrow that'll be great. I have enough
> other things to do today ...

Looks good to me. I was and am still nervous of weird knock-on effects,
but I think its the right patch to apply.

There's a whole wedge of new functionality there, so beta should be fun.

We need to reword the doc section about time travel, but I'll let you
tackle that bit, at least for now.

--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com

Simon Riggs wrote:
> ...knock-on...
> ....tackle....

Been watching the Rugby World Cup? :)

Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> On Thu, 2007-09-27 at 13:01 -0400, Tom Lane wrote:
>> Anyway, if you can test this tomorrow that'll be great. I have enough
>> other things to do today ...

> Looks good to me. I was and am still nervous of weird knock-on effects,
> but I think its the right patch to apply.

Me too --- committed and back-patched.

> We need to reword the doc section about time travel, but I'll let you
> tackle that bit, at least for now.

Right, done.

BTW, I realized that the reason I objected to your "option #4"
originally was that I thought you were proposing to make *every*
recovery start a new timeline. It's not hard to imagine
sorcerer's-apprentice problems in a repeated crash and restart scenario.
But actually this is just starting one new timeline per (successful)
archive recovery, and each one of those will require manual intervention
to kick it off; so it's pretty much impossible to believe an
installation would ever create an untenable number of timelines.

regards, tom lane

On Thu, 27 Sep 2007, Tom Lane wrote:

> Also, I spent a dreary two or three hours this afternoon examining the
> CVS commit logs since 8.3 branched...I tried to post that info to
> pgsql-docs but it broke the list's message size limits (even gzipped,
> it's about 90K).

I just dumped a copy of Tom's file on my personal page and posted a much
slimmed down version that's missing the names of the files touched onto
the wiki at http://developer.postgresql.org/index.php/8.3_Changelog (with
a pointer to the full text in case anyone needs to dig back into the
details to figure out what a commit touched).

There was already an outline for building the release notes into at
http://developer.postgresql.org/index.php/8.3release

What I was thinking might be a useful way for multiple people to hack away
at this problem is to start fleshing out the standard release note
one-line summaries onto the one page, then delete the relevant commits
from the other. When the changelog page is empty, then everything is
documented.

I didn't actually start doing this though as I didn't want to dump any
more time into a process that may not actually be used.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Greg Smith wrote:
> On Thu, 27 Sep 2007, Tom Lane wrote:
>
>> Also, I spent a dreary two or three hours this afternoon examining the
>> CVS commit logs since 8.3 branched...I tried to post that info to
>> pgsql-docs but it broke the list's message size limits (even gzipped,
>> it's about 90K).

Bruce you mentioned in a post earlier this week that you were going to
jump back on the release notes. Earlier last week, I said I would jump
on them as did Greg.

Greg went through the effort to do the below... shall we use it together?

Joshua D. Drake

>
> I just dumped a copy of Tom's file on my personal page and posted a much
> slimmed down version that's missing the names of the files touched onto
> the wiki at http://developer.postgresql.org/index.php/8.3_Changelog
> (with a pointer to the full text in case anyone needs to dig back into
> the details to figure out what a commit touched).
>
> There was already an outline for building the release notes into at
> http://developer.postgresql.org/index.php/8.3release
>
> What I was thinking might be a useful way for multiple people to hack
> away at this problem is to start fleshing out the standard release note
> one-line summaries onto the one page, then delete the relevant commits
> from the other. When the changelog page is empty, then everything is
> documented.
>
> I didn't actually start doing this though as I didn't want to dump any
> more time into a process that may not actually be used.
>
> --
> * Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
>

- --

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240
PostgreSQL solutions since 1997 http://www.commandprompt.com/
UNIQUE NOT NULL
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHBAWGATb/zqfZUUQRAt/sAKCjvXWSJ0J4N6Vp5HlokJqeSt22QwCglGJw
996PY4JCX+o6AfhrDftOiJ0=
=eEQw
-----END PGP SIGNATURE-----

Joshua D. Drake wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Greg Smith wrote:
> > On Thu, 27 Sep 2007, Tom Lane wrote:
> >
> >> Also, I spent a dreary two or three hours this afternoon examining the
> >> CVS commit logs since 8.3 branched...I tried to post that info to
> >> pgsql-docs but it broke the list's message size limits (even gzipped,
> >> it's about 90K).
>
> Bruce you mentioned in a post earlier this week that you were going to
> jump back on the release notes. Earlier last week, I said I would jump
> on them as did Greg.
>
> Greg went through the effort to do the below... shall we use it together?

Too late. Tom already did a lot of the work. See

http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/release.sgml?r1=1.508&r2=1.509

or the HTML version at
http://momjian.us/main/writings/pgsql/sgml/release-8-3.html

--
Alvaro Herrera http://www.amazon.com/gp/registry/5ZYLFMCVHXC
"Ellos andaban todos desnudos como su madre los parió, y también las mujeres,
aunque no vi más que una, harto moza, y todos los que yo vi eran todos
mancebos, que ninguno vi de edad de más de XXX años" (Cristóbal Colón)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alvaro Herrera wrote:
> Joshua D. Drake wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Greg Smith wrote:
>>> On Thu, 27 Sep 2007, Tom Lane wrote:
>>>
>>>> Also, I spent a dreary two or three hours this afternoon examining the
>>>> CVS commit logs since 8.3 branched...I tried to post that info to
>>>> pgsql-docs but it broke the list's message size limits (even gzipped,
>>>> it's about 90K).
>> Bruce you mentioned in a post earlier this week that you were going to
>> jump back on the release notes. Earlier last week, I said I would jump
>> on them as did Greg.
>>
>> Greg went through the effort to do the below... shall we use it together?
>
> Too late. Tom already did a lot of the work. See
>
> http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/release.sgml?r1=1.508&r2=1.509
>
> or the HTML version at
> http://momjian.us/main/writings/pgsql/sgml/release-8-3.html

Right... I believe... that was first run though, at which point he asked
for helpers to which greg and I responded.

I could be wrong?

Joshua D. Drake

>

- --

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240
PostgreSQL solutions since 1997 http://www.commandprompt.com/
UNIQUE NOT NULL
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHBAv7ATb/zqfZUUQRAsHeAJ0XhEY+7/Qr12bT5mD3g2c1wr+SaQCfaJD/
+3AApwJxH/px8f77F4jq/Ug=
=+n1R
-----END PGP SIGNATURE-----

"Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
> Alvaro Herrera wrote:
>> Too late. Tom already did a lot of the work. See
>> http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/release.sgml?r1=1.508&r2=1.509

> Right... I believe... that was first run though, at which point he asked
> for helpers to which greg and I responded.

That was last week ... I didn't see anything happening so I went back to
it.

At this point the bulk of the work is done, except for SGML markup
prettification.

regards, tom lane

Hi,

On 10/4/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> At this point the bulk of the work is done, except for SGML markup
> prettification.

There is a typo in the contrib part:
# Add GIN support for hstore (Guillaume Smet, Teodor)
# Add GIN support for pg_trgm (Guillaume Smet, Teodor0

s/Teodor0/Teodor)/

And I didn't participate to the GIN support of hstore, I just added it
to pg_trgm with the help of Teodor so it should be Teodor alone on
hstore GIN support.

Regards,

--
Guillaume

On Thu, 2007-10-04 at 09:04 +0200, Guillaume Smet wrote:
> There is a typo in the contrib part:
> # Add GIN support for hstore (Guillaume Smet, Teodor)
> # Add GIN support for pg_trgm (Guillaume Smet, Teodor0
>
> s/Teodor0/Teodor)/
>
> And I didn't participate to the GIN support of hstore, I just added it
> to pg_trgm with the help of Teodor so it should be Teodor alone on
> hstore GIN support.

Fixed, thanks.

-Neil

Alvaro Herrera wrote:
> > Greg Smith wrote:
> > > On Thu, 27 Sep 2007, Tom Lane wrote:
> > >
> > >> Also, I spent a dreary two or three hours this afternoon examining the
> > >> CVS commit logs since 8.3 branched...I tried to post that info to
> > >> pgsql-docs but it broke the list's message size limits (even gzipped,
> > >> it's about 90K).
> >
> > Bruce you mentioned in a post earlier this week that you were going to
> > jump back on the release notes. Earlier last week, I said I would jump
> > on them as did Greg.
> >
> > Greg went through the effort to do the below... shall we use it together?
>
> Too late. Tom already did a lot of the work. See
>
> http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/release.sgml?r1=1.508&r2=1.509
>
> or the HTML version at
> http://momjian.us/main/writings/pgsql/sgml/release-8-3.html

Sorry I dropped the ball on the release notes. My wife had minor
surgery last Monday and I hoped to be freed up earlier but the recovery
was longer than expected. I am back to reading email now. Thanks to Tom
for doing the release notes, and to others for helping.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +