> > 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]> 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-exp
* 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
>>> On Thu, Sep 27, 2007 at 6:56 AM, in message
<[EMAIL PROTECTED]>, Simon Riggs <[EMAIL PROTECTED]>
wrote:
> On Wed, 2007-09-26 at 16:31 -0500, Kevin Grittner wrote:
>
>> The one downside I've found is that it adds 0.2
>> seconds of CPU time per WAL file archive during our heaviest update
>> pe
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
I wrote:
> The problem here is that in the output of the grammar, * is represented
> exactly the same as "*" would be ... I suppose this representation was
> chosen back in the day before we had full support for quoted column
> names.
I took a brief look at this. Changing that representation seem
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
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> NikhilS wrote:
>> One of our qmg folks reported an assertion failure:
>> create table x(y char(1));
>> insert into x values ("*");
>>
>> The above causes the following assertion to be hit:
> Works for me on CVS HEAD. Which version of Postgres is t
>>> On Wed, Sep 26, 2007 at 7:29 PM, in message <[EMAIL PROTECTED]>,
"Florian G. Pflug" <[EMAIL PROTECTED]> wrote:
> Kevin Grittner wrote:
>> I omitted the code I was originally considering to have it work against
>> files "in place" rather than as a filter. It seemed much simpler this
>> way, w
NikhilS wrote:
> One of our qmg folks reported an assertion failure:
>
> create table x(y char(1));
> insert into x values ("*");
>
> The above causes the following assertion to be hit:
Works for me on CVS HEAD. Which version of Postgres is this?
--
Heikki Linnakangas
EnterpriseDB http:
>>> On Thu, Sep 27, 2007 at 6:56 AM, in message
<[EMAIL PROTECTED]>, Simon Riggs <[EMAIL PROTECTED]>
wrote:
> On Wed, 2007-09-26 at 16:31 -0500, Kevin Grittner wrote:
>
>> The one downside I've found is that it adds 0.2
>> seconds of CPU time per WAL file archive during our heaviest update
>> pe
>>> On Thu, Sep 27, 2007 at 3:17 AM, in message
<[EMAIL PROTECTED]>, "Zeugswetter
Andreas ADI SD" <[EMAIL PROTECTED]> wrote:
>
> The probably useful next step would be to pass the current length to the
> archive_command,
> so it can write the filled part of the file without the need for a
> filt
Hi,
One of our qmg folks reported an assertion failure:
create table x(y char(1));
insert into x values ("*");
The above causes the following assertion to be hit:
/*
* Target item is a bare '*', expand all tables
*
* (e.g., SELECT * FROM emp, dept)
*
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> That's not fixing the problem, unless your proposal includes never
>> issuing any warnings at all, for anything.
> No warning for "*" because it is intentional, but warning for actual
> stop words.
No, you're focusing on one symptom n
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> So far, I've got the following functions doing the work:
> char * text_cstring(text *t)
> char * text_cstring_limit(text *t, int len)
> text * cstring_text(char *s)
> It wouldn't be difficult at this point to make those functions
> 'varlena' rather tha
On 9/22/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> On grounds of code-space savings I think it might be worth making
> these things be simple functions declared in builtins.h; that would
> also make it much easier to change their implementations.
I've noticed that this pattern isn't exclusive to th
On Wed, 2007-09-26 at 16:31 -0500, Kevin Grittner wrote:
> The one downside I've found is that it adds 0.2
> seconds of CPU time per WAL file archive during our heaviest update
> periods. It's in the archiver process, not a backend process that's
> running a query, and we're not generally CPU bou
On Thu, 2007-09-27 at 10:17 +0200, Zeugswetter Andreas ADI SD wrote:
> > > Attached is a modified version to implement both of these. I also
> bailed
> > > out if there was surplus input. I tried an optimization of
> allocating a
> > > separate buffer for outputting the zeros, to avoid repeated m
On Thu, Sep 27, 2007 at 12:15:24PM +0200, Lukas Kahwe Smith wrote:
> >It's been on the TODO list for at least 5 years...
>
> Wow, I was not aware of this limitation. MySQL hacks around this issue
> by allowing an ORDER BY in UPDATE (and DELETE) statements.
There is a similar workaround for postg
Martijn van Oosterhout wrote:
On Thu, Sep 27, 2007 at 02:48:52PM +0530, Anoo Sivadasan Pillai wrote:
Description : I have two tables with the same data , While I issue an
update command to increment the value of a unique field by 1, the
statement fails in one table and will succeed in the othe
On Thu, Sep 27, 2007 at 02:48:52PM +0530, Anoo Sivadasan Pillai wrote:
> Description : I have two tables with the same data , While I issue an
> update command to increment the value of a unique field by 1, the
> statement fails in one table and will succeed in the other table.
> Following is the
Anoo Sivadasan Pillai wrote:
Even though many of the list members of [EMAIL PROTECTED]
suggest that the following is an expected behaviour, my experience in
other databases doesn't permit me accept it as such. I am putting this
for the kind consideration of this list
I think it's more of a "kn
Even though many of the list members of [EMAIL PROTECTED]
suggest that the following is an expected behaviour, my experience in
other databases doesn't permit me accept it as such. I am putting this
for the kind consideration of this list
Description : I have two tables with the same data ,
> > Attached is a modified version to implement both of these. I also
bailed
> > out if there was surplus input. I tried an optimization of
allocating a
> > separate buffer for outputting the zeros, to avoid repeated memset
calls.
> > It didn't seem to make a very big difference; do you think it
On Thu, 2007-09-27 at 08:31 +0100, Heikki Linnakangas wrote:
> Kevin Grittner wrote:
> > <[EMAIL PROTECTED]>, Simon Riggs <[EMAIL PROTECTED]>
> > wrote:
> >> We should also document that this is designed to help compress files
> >> that aren't full because we switched early because of archive_time
Kevin Grittner wrote:
> <[EMAIL PROTECTED]>, Simon Riggs <[EMAIL PROTECTED]>
> wrote:
>> We should also document that this is designed to help compress files
>> that aren't full because we switched early because of archive_timeout.
>
> Attached is a modified version to implement both of these.
57 matches
Mail list logo
