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
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
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
s/Teodor0/T
"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.508&r2=1.509
> Right... I believe... that was first run though, at which point he asked
> f
-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
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
-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 siz
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 f
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 rig
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 do
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
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.
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* par
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
w
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 head
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:
Eac
* 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
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
> http://developer.postgresql.org/index.php/Wh
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, ker
"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
> > * 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
> > 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 whe
"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 ar
-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 h
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/Whats
> 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 explic
* 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 ha
"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
* [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 cou
-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 l
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 ca
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 disambigu
[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/What
* 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
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
* 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
> > whe
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 t
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
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 w
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.
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 archi
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
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 s
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 cru
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
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 function
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 cru
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.
>
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
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,
> http://archives.postgresql.org/pgsql-hackers/
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
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 rath
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 el
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 issu
* 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:
* Inde
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
56 matches
Mail list logo
