Sorry, my day job is currently taking up all my spare cycles :( So I
don't think I'll get a chance to wrap this up for 8.3.
My recollection is that the patch was okay as far as it went, but I'm
hesitant to add yet another alternative to the already complex set of
choices for returning
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Greg Smith wrote:
I'm mostly done with my review of the Automatic adjustment of
bgwriter_lru_maxpages patch. In
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
I don't really see why it's overkill.
Well I
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Simon Riggs wrote:
On Thu, 2007-06-28 at 20:23 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Josh Berkus wrote:
All,
I'm working on cleaning up postgresql.conf and pg_settings for the
release. Attached
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Simon Riggs wrote:
On Sat, 2007-07-21 at 12:20 +0100, Simon Riggs wrote:
I'd like to help where I can if nobody
Just confirming, this should be applied to 8.3, right?
---
Zdenek Kotala wrote:
Stefan reported me that prcrypto regression test fails on solaris 10
with openssl support. I investigated this problem and the result is
Bruce Momjian wrote:
Just confirming, this should be applied to 8.3, right?
I think marko is working on an updated patch for this:
http://archives.postgresql.org/pgsql-hackers/2007-09/msg00386.php
without that the backend will coredump if ones uses string ciphers with
pgcrypto on a default
I looked for another thread-unsafe usage of variables like prep_stmts,
and I found the 4 possibly-unsafe ones:
[1] all_descriptors in ecpg/ecpglib/descriptor.c:
Management of descriptors used by SQL DESCRIPTOR is not safe.
[2] auto_allocs in ecpg/ecpglib/memory.c:
All memory
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Simon Riggs wrote:
On Mon, 2007-09-10 at 10:21 -0400, Tom Lane wrote:
Oleg Bartunov [EMAIL PROTECTED] writes:
On Wed, 2007-09-26 at 04:33 -0400, Bruce Momjian wrote:
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
Already applied.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
---(end of
Here is the talk I gave in Moscow highlighting 8.3 performance features:
http://momjian.us/main/writings/pgsql/features.pdf
--
Bruce Momjian [EMAIL PROTECTED] http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a
On Wed, Sep 26, 2007 at 05:56:59PM +0900, ITAGAKI Takahiro wrote:
[1] all_descriptors in ecpg/ecpglib/descriptor.c:
Management of descriptors used by SQL DESCRIPTOR is not safe.
[2] auto_allocs in ecpg/ecpglib/memory.c:
All memory allocation for statements are not safe.
Mark,
Very interesting. I'm looking for such tool.
Unfortunately, I can't compile it on my Solaris right now,
but I hope it will be shipped with PostgreSQL distribution.
Mark Wong wrote:
Hi everyone,
I was playing with converting unixtop (the version of top used in
FreeBSD) to only show
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Martin Pihlak wrote:
Howdy,
Here's an updated version of the function stats patch. The biggest change is
that
On Tue, Sep 25, 2007 at 03:25:08PM +0200, Magnus Hagander wrote:
/* exec sql type customer is struct { #line 12 array_of_struct.pgc
struct varchar_name_12 { int len; char arr[ 50 ]; } name; #line 13
array_of_struct.pgc int phone; } */ #line 14
array_of_struct.pgc
...
On Wed, Sep 26, 2007 at 01:07:04PM +0200, Michael Meskes wrote:
On Tue, Sep 25, 2007 at 03:25:08PM +0200, Magnus Hagander wrote:
/* exec sql type customer is struct { #line 12 array_of_struct.pgc
struct varchar_name_12 { int len; char arr[ 50 ]; } name; #line
13
Hi All,
I am trying to run Regression test on postgreSQL-7.2.8, it got installed
successfully, but the regression test is not going through, it is giving the
following errors...
==
78 of 79 tests passed, 1 failed test(s) ignored.
Kuriakose, Cinu Cheriyamoozhiyil [EMAIL PROTECTED] writes:
Hi All,
I am trying to run Regression test on postgreSQL-7.2.8, it got installed
successfully, but the regression test is not going through, it is giving the
following errors...
What architecture is this? And why would you be
On Wed, Sep 26, 2007 at 01:15:21PM +0200, Magnus Hagander wrote:
This might be too simple but are you sure ecpg is called with option
-c when compiling array_of_struct.pgc? It is listed that way in the
Makefile, however lacking this option should generate exactly the file
you sent.
This might be too simple but are you sure ecpg is called with option
-c when compiling array_of_struct.pgc? It is listed that way in the
Makefile, however lacking this option should generate exactly the file
you sent.
Well, bingo. With that, ti passes that check. Oops. Will commit
On Thu, Sep 20, 2007 at 05:34:32PM -0700, Neil Conway wrote:
That seems a confusing set of values. Perhaps off, pl, and all
would be clearer?
I'm curious if you've measured the performance overhead of enabling this
functionality.
i'm quite worried about all setting.
all operators are
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
hubert depesz lubaczewski wrote:
On Thu, Sep 20, 2007 at 05:34:32PM -0700, Neil Conway wrote:
That seems a confusing set of values. Perhaps off, pl, and all
would be clearer?
I'm curious if you've measured the performance overhead of enabling this
functionality.
i'm quite worried about all
On Wed, Sep 26, 2007 at 02:12:55PM +0200, Magnus Hagander wrote:
Not really, it looks like you're using -c on this file too. This one,
however, is supposed to be compiled without -c.
Indeed I am, I changed all of the invocations. on my cell now so can't read
the code - how do I determine
Hi Tom/ Heikki,
Thanks for the suggestion. After profiling i got similar results.
So i am thinking of a design like this to get the performance improvement.
a) We can get one page for insert(during update) and we will hold the write
lock on it, till the page gets filled. In this way,
Kuriakose, Cinu Cheriyamoozhiyil [EMAIL PROTECTED] writes:
78 of 79 tests passed, 1 failed test(s) ignored.
Please tell me what shall I do to resolve this issue.
Nothing --- the reason it's ignored is it's not significant.
I concur though with Greg's question: why aren't you building
Stefan Kaltenbrunner wrote:
Bruce Momjian wrote:
Just confirming, this should be applied to 8.3, right?
I think marko is working on an updated patch for this:
http://archives.postgresql.org/pgsql-hackers/2007-09/msg00386.php
without that the backend will coredump if ones uses string ciphers
I have a CREATE TABLE statement where I am trying to initialize
several inet fields, e.g.
CREATE TABLE myConfigTable
(
telnetbool DEFAULT
FALSE,
ftp bool DEFAULT
FALSE,
ipForwarding bool DEFAULT
FALSE,
configIntControlNetw inet DEFAULT
fimarn [EMAIL PROTECTED] writes:
When I try to execute an INSERT statement associated with this table I
am getting:
NOTICE: failed to convert IP address string, invalid inetstruct len
Your example works fine for me:
regression=# insert into myConfigTable default values;
INSERT 0 1
The PGBuildfarm member dugong had the following event on branch HEAD:
Status changed from OK to ContribCheck failure
The snapshot timestamp for the build that triggered this notification is:
2007-09-25 20:05:01
This seems to be exactly what we saw two weeks ago, and I just noticed
that in
Andrew Dunstan wrote:
Zdenek Kotala wrote:
Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
We previously discussed compressing the numeric data type for small
values:
http://archives.postgresql.org/pgsql-hackers/2007-06/msg00715.php
We didn't do this for 8.3 but in any case
On Mon, Sep 24, 2007 at 4:17 PM, in message
[EMAIL PROTECTED], Kevin Grittner
[EMAIL PROTECTED] wrote:
On Thu, Sep 6, 2007 at 7:03 PM, in message
[EMAIL PROTECTED], Jeff Davis [EMAIL PROTECTED]
wrote:
I think ... there's still room for a simple tool that can zero out
the meaningless
On 9/25/07, Luke Lonergan [EMAIL PROTECTED] wrote:
Hi Mark,
I haven't yet looked at what you've done, but I'm an enthusiastic supporter
of this idea. We're looking to do something that will view running queries
and allow drill down into those executing at any given time, showing their
plans
On 9/25/07, Euler Taveira de Oliveira [EMAIL PROTECTED] wrote:
Mark Wong wrote:
Hi everyone,
I was playing with converting unixtop (the version of top used in
FreeBSD) to only show PostgreSQL processes pulled from the
pg_stat_activity table. I have a version that kind of works here:
On 9/25/07, Satoshi Nagayasu [EMAIL PROTECTED] wrote:
Mark,
Very interesting. I'm looking for such tool.
Unfortunately, I can't compile it on my Solaris right now,
but I hope it will be shipped with PostgreSQL distribution.
I haven't tried it on Solaris but I'm not surprised. If I can get
On 9/24/07, Gregory Stark [EMAIL PROTECTED] wrote:
We previously discussed compressing the numeric data type for small values:
http://archives.postgresql.org/pgsql-hackers/2007-06/msg00715.php
We didn't do this for 8.3 but in any case Tom did suggest we ought to reverse
the weight and
Gokulakannan Somasundaram wrote:
Hi Tom/ Heikki,
Thanks for the suggestion. After profiling i got similar results.
So i am thinking of a design like this to get the performance improvement.
a) We can get one page for insert(during update) and we will hold the write
lock on it,
Merlin Moncure [EMAIL PROTECTED] writes:
would this break any application pulling a numeric field as binary
over the protocol?
No.
regards, tom lane
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL
On Wed, 2007-09-26 at 11:05 -0500, Kevin Grittner wrote:
Lacking any suggestions, I plowed ahead with something which satisfies
our needs. First, rough, version attached. It'll save us buying another
drawer of drives, so it was worth a few hours of research to figure out
how to do it.
Alvaro Herrera wrote:
How about we change it to MaxHeapTuplesPerPage for now. That closes all
complaints in this thread.
Done, thanks for the input!
--
Alvaro Herrera http://www.amazon.com/gp/registry/CTMLCN8V17R4
La rebeldía es la virtud original del hombre (Arthur
On Wed, Sep 26, 2007 at 3:14 PM, in message
[EMAIL PROTECTED], Simon Riggs [EMAIL PROTECTED]
wrote:
It's nicely written
Thanks. I spent some time looking at Tom Lane's pg_resetxlog and the
source code for cat to model my code. I'm rather rusty on C, so I wanted
to minimize the chance of
On Wed, Sep 26, 2007 at 3:14 PM, in message
[EMAIL PROTECTED], Simon Riggs [EMAIL PROTECTED]
wrote:
The logic for zeroing the blocks makes me nervous. It doesn't locate the
block from which to start, it treats all blocks equally, so might zero
some blocks and not others. What you have
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 have a use case for the additional functionality,
and it seemed safer as a filter. Thoughts?
A special
Mark Wong wrote:
On 9/25/07, Satoshi Nagayasu [EMAIL PROTECTED] wrote:
Mark,
Very interesting. I'm looking for such tool.
Unfortunately, I can't compile it on my Solaris right now,
but I hope it will be shipped with PostgreSQL distribution.
I haven't tried it on Solaris but I'm not
On 9/26/07, Zdenek Kotala [EMAIL PROTECTED] wrote:
Mark Wong wrote:
On 9/25/07, Satoshi Nagayasu [EMAIL PROTECTED] wrote:
Mark,
Very interesting. I'm looking for such tool.
Unfortunately, I can't compile it on my Solaris right now,
but I hope it will be shipped with PostgreSQL
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Simon Riggs wrote:
On Sat, 2007-03-31 at 00:51 +0200, Florian G. Pflug wrote:
Simon Riggs wrote:
On Fri,
I just talked to Teodor and we discussed this problem. My idea is to
have a special marker in the synonym table, perhaps * to indicate the
presence of _any_ stop word at that location. This will not produce any
warnings because it is clearly intentional. The original warning for a
literal stop
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Neil Conway wrote:
To review, Pavel Stehule submitted a proposal and patch to add support
for table functions a
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Simon Riggs wrote:
On Sun, 2007-06-10 at 20:48 +0200, [EMAIL PROTECTED] wrote:
My questions was: why don't
Bruce Momjian [EMAIL PROTECTED] writes:
I just talked to Teodor and we discussed this problem. My idea is to
have a special marker in the synonym table, perhaps * to indicate the
presence of _any_ stop word at that location. This will not produce any
warnings because it is clearly
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I just talked to Teodor and we discussed this problem. My idea is to
have a special marker in the synonym table, perhaps * to indicate the
presence of _any_ stop word at that location. This will not produce any
warnings because it
52 matches
Mail list logo
