Thread: 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@sigaev.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@postgresql.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@2ndquadrant.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 newtimeline and must assign it a unique new ID. * Otherwise, we can just extend the timeline we were in when we ranout * 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 newtimeline 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 timelinewe 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
On Thu, 2007-09-27 at 12:07 -0400, Tom Lane wrote: > Simon Riggs <simon@2ndquadrant.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
Andrew Dunstan <ad-ags@dunslane.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
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
Heikki Linnakangas <heikki@enterprisedb.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
Simon Riggs <simon@2ndquadrant.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: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
On Thu, 2007-09-27 at 12:45 -0400, Tom Lane wrote: > Simon Riggs <simon@2ndquadrant.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@dunslane.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@2ndquadrant.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@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
Martijn van Oosterhout <kleptog@svana.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
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, Sep 27, 2007 at 01:07:33PM -0400, Tom Lane wrote: > Martijn van Oosterhout <kleptog@svana.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@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
* Heikki Linnakangas (heikki@enterprisedb.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
Stephen Frost <sfrost@snowman.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@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.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
teodor@sigaev.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
Tom Lane wrote: >Stephen Frost <sfrost@snowman.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@postgresql.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.Kotala@Sun.COM (Zdenek.Kotala@Sun.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@sss.pgh.pa.us> writes: > Stephen Frost <sfrost@snowman.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@enterprisedb.com) wrote:
> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
> > Stephen Frost <sfrost@snowman.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@enterprisedb.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@postgresql.org so that your > message can get through to the mailing list cleanly
Tatsuo Ishii <ishii@postgresql.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@postgresql.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@postgresql.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@commandprompt.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@snowman.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@sss.pgh.pa.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 expressionsevaluation (with Namespaces support) * Alternative XML export function -- Best regards, Nikolay
* Heikki Linnakangas (heikki@enterprisedb.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.Kotala@Sun.COM (Zdenek.Kotala@Sun.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.Kotala@Sun.COM (Zdenek.Kotala@Sun.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@enterprisedb.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@2ndquadrant.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@2ndquadrant.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@gregsmith.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@gregsmith.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@commandprompt.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@sss.pgh.pa.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@momjian.us> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +