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
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 int
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
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
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 sto
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,
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 shipp
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 surpris
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 "n
>>> 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
>>> 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 ch
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 Schop
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.
>
"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
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
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
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 c
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 wo
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
>>> 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 z
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
> 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
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
regre
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
'1.1.0
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
"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 so
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,
R
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
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 "
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
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 a
> > > 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.
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
"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
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.
==
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
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_s
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
> tha
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 Postg
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.
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 h
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 broadcast)--
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:
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 alloc
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 s
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 th
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 nob
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. Attach
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:
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".
>
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.
51 matches
Mail list logo
