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
Hi,
On 10/4/07, Tom Lane [EMAIL PROTECTED] 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
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
-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
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
-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
Joshua D. Drake [EMAIL PROTECTED] 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.508r2=1.509
Right... I believe... that was first run though, at which point he asked
for helpers
* 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
* Heikki Linnakangas ([EMAIL PROTECTED]) 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
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
Heikki Linnakangas [EMAIL PROTECTED] 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
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,
Zdenek Kotala wrote:
Stephen Frost wrote:
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) 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
Stephen Frost [EMAIL PROTECTED] 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
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
On 9/27/07, Tom Lane [EMAIL PROTECTED] 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
Stephen Frost wrote:
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) 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:
On Thu, 2007-09-27 at 13:01 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] 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
Simon Riggs wrote:
...knock-on...
tackle
Been watching the Rugby World Cup? :)
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes
Simon Riggs [EMAIL PROTECTED] 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
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
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,
* 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:
*
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,
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
Simon Riggs [EMAIL PROTECTED] 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
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
On Thu, 2007-09-27 at 12:07 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] 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,
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
Andrew Dunstan [EMAIL PROTECTED] 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
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.
Heikki Linnakangas [EMAIL PROTECTED] 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,
Simon Riggs [EMAIL PROTECTED] 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
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.
On Thu, 2007-09-27 at 12:45 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] 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
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] 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
Simon Riggs [EMAIL PROTECTED] 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
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
Martijn van Oosterhout [EMAIL PROTECTED] 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).
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
On Thu, Sep 27, 2007 at 01:07:33PM -0400, Tom Lane wrote:
Martijn van Oosterhout [EMAIL PROTECTED] 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
* Heikki Linnakangas ([EMAIL PROTECTED]) 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
Stephen Frost [EMAIL PROTECTED] 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
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] 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
[EMAIL PROTECTED] (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
Tom Lane wrote:
Stephen Frost [EMAIL PROTECTED] 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
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
-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
Tom Lane [EMAIL PROTECTED] writes:
Stephen Frost [EMAIL PROTECTED] 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
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) 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
* Gregory Stark ([EMAIL PROTECTED]) wrote:
Tom Lane [EMAIL PROTECTED] writes:
Stephen Frost [EMAIL PROTECTED] 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
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
Tatsuo Ishii [EMAIL PROTECTED] 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
Tatsuo Ishii [EMAIL PROTECTED] 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
Joshua D. Drake [EMAIL PROTECTED] 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
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
56 matches
Mail list logo
