Re: [HACKERS] [FEATURE REQUEST] Streaming Onlinebackup (MaybeOFFTOPIC)

2007-09-27 Thread Heikki Linnakangas
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. I also

Re: [HACKERS] [FEATURE REQUEST] Streaming Onlinebackup (MaybeOFFTOPIC)

2007-09-27 Thread Simon Riggs
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_timeout.

Re: [HACKERS] [FEATURE REQUEST] Streaming Onlinebackup (MaybeOFFTOPIC)

2007-09-27 Thread Zeugswetter Andreas ADI SD
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's

[HACKERS] Change request ...

2007-09-27 Thread Anoo Sivadasan Pillai
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 ,

Re: [HACKERS] Change request ...

2007-09-27 Thread Richard Huxton
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

Re: [HACKERS] Change request ...

2007-09-27 Thread Martijn van Oosterhout
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

Re: [HACKERS] Change request ...

2007-09-27 Thread Lukas Kahwe Smith
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

Re: [HACKERS] Change request ...

2007-09-27 Thread Martijn van Oosterhout
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 postgres

Re: [HACKERS] [FEATURE REQUEST] Streaming Onlinebackup (MaybeOFFTOPIC)

2007-09-27 Thread Simon Riggs
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 memset

Re: [HACKERS] [FEATURE REQUEST] Streaming Onlinebackup (Maybe OFFTOPIC)

2007-09-27 Thread Simon Riggs
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 bound,

Re: [HACKERS] Text - C string

2007-09-27 Thread Brendan Jurd
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 the

Re: [HACKERS] Text - C string

2007-09-27 Thread Tom Lane
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 than 'text',

Re: [HACKERS] [COMMITTERS] pgsql: Temporarily modify tsearch regression tests to suppress notice

2007-09-27 Thread Tom Lane
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 not the

[HACKERS] Assertion failure due to ColumnRefStar

2007-09-27 Thread NikhilS
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) *

Re: [HACKERS] [FEATURE REQUEST] Streaming Onlinebackup (MaybeOFFTOPIC)

2007-09-27 Thread Kevin Grittner
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 filter. I can

Re: [HACKERS] [FEATURE REQUEST] Streaming Onlinebackup (Maybe OFFTOPIC)

2007-09-27 Thread Kevin Grittner
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 periods. OK,

Re: [HACKERS] Assertion failure due to ColumnRefStar

2007-09-27 Thread Heikki Linnakangas
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

Re: [HACKERS] [FEATURE REQUEST] Streaming Onlinebackup (Maybe OFFTOPIC)

2007-09-27 Thread Kevin Grittner
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, we didn't actually

Re: [HACKERS] Assertion failure due to ColumnRefStar

2007-09-27 Thread Tom Lane
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 this? I see the

[HACKERS] Getting to 8.3 beta1

2007-09-27 Thread 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,

Re: [HACKERS] Getting to 8.3 beta1

2007-09-27 Thread Teodor Sigaev
* 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: *

Re: [HACKERS] Getting to 8.3 beta1

2007-09-27 Thread Simon Riggs
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,

Re: [HACKERS] Getting to 8.3 beta1

2007-09-27 Thread Darcy Buskermolen
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

Re: [HACKERS] Getting to 8.3 beta1

2007-09-27 Thread Tom Lane
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

Re: [HACKERS] Getting to 8.3 beta1

2007-09-27 Thread 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

Re: [HACKERS] Getting to 8.3 beta1

2007-09-27 Thread Simon Riggs
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,

Re: [HACKERS] Getting to 8.3 beta1

2007-09-27 Thread Heikki Linnakangas
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

Re: [HACKERS] Getting to 8.3 beta1

2007-09-27 Thread Tom Lane
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

Re: [HACKERS] Getting to 8.3 beta1

2007-09-27 Thread Simon Riggs
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.

Re: [HACKERS] Getting to 8.3 beta1

2007-09-27 Thread Tom Lane
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,

Re: [HACKERS] Getting to 8.3 beta1

2007-09-27 Thread Tom Lane
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

Re: [HACKERS] Getting to 8.3 beta1

2007-09-27 Thread Simon Riggs
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.

Re: [HACKERS] Getting to 8.3 beta1

2007-09-27 Thread Simon Riggs
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

Re: [HACKERS] Assertion failure due to ColumnRefStar

2007-09-27 Thread Tom Lane
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 seems

Re: [HACKERS] Getting to 8.3 beta1

2007-09-27 Thread Andrew Dunstan
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

Re: [HACKERS] Getting to 8.3 beta1

2007-09-27 Thread Tom Lane
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

Re: [HACKERS] Getting to 8.3 beta1

2007-09-27 Thread Martijn van Oosterhout
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

Re: [HACKERS] Getting to 8.3 beta1

2007-09-27 Thread Tom Lane
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).

Re: [HACKERS] Getting to 8.3 beta1

2007-09-27 Thread Andrew Dunstan
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

Re: [HACKERS] Getting to 8.3 beta1

2007-09-27 Thread Martijn van Oosterhout
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

Re: [HACKERS] Getting to 8.3 beta1

2007-09-27 Thread Stephen Frost
* 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

Re: [HACKERS] Getting to 8.3 beta1

2007-09-27 Thread Tom Lane
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

Re: [HACKERS] Getting to 8.3 beta1

2007-09-27 Thread Stephen Frost
* 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

Re: [HACKERS] Getting to 8.3 beta1

2007-09-27 Thread Chris Browne
[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

Re: [pgsql-packagers] [HACKERS] Getting to 8.3 beta1

2007-09-27 Thread Zdenek . Kotala
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

Re: [HACKERS] Getting to 8.3 beta1

2007-09-27 Thread Zdenek . Kotala
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

Re: [HACKERS] [FEATURE REQUEST] Streaming Onlinebackup (Maybe OFFTOPIC)

2007-09-27 Thread Kevin Grittner
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 periods. It's

Re: [HACKERS] Getting to 8.3 beta1

2007-09-27 Thread Joshua D. Drake
-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

Re: [HACKERS] Getting to 8.3 beta1

2007-09-27 Thread Gregory Stark
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

Re: [pgsql-packagers] [HACKERS] Getting to 8.3 beta1

2007-09-27 Thread Stephen Frost
* [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

Re: [HACKERS] [pgsql-packagers] Getting to 8.3 beta1

2007-09-27 Thread Tom Lane
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

Re: [HACKERS] Getting to 8.3 beta1

2007-09-27 Thread Stephen Frost
* 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

Re: [HACKERS] Getting to 8.3 beta1

2007-09-27 Thread Tatsuo Ishii
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

Re: [HACKERS] Getting to 8.3 beta1

2007-09-27 Thread Joshua D. Drake
-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

Re: [HACKERS] Getting to 8.3 beta1

2007-09-27 Thread Tom Lane
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

Re: [HACKERS] Getting to 8.3 beta1

2007-09-27 Thread Tom Lane
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

Re: [HACKERS] Getting to 8.3 beta1

2007-09-27 Thread Pavel Stehule
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