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 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@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
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@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
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
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@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: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/
Show quoted text
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
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.
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/
Show quoted text
From each according to his ability. To each according to his ability to litigate.
