On Wed, 2009-05-20 at 23:01 -0400, Zdenek Kotala wrote:
> We use default one. I did not tested difference between them, but IIRC
> that Jignesh did some testing with umem. I will ask him. However if you
> give me test scenario I can test it.
Talk with Dimitri from Sun who is doing scalability be
2009/5/21 Steve Prentice :
> On May 20, 2009, at 10:24 AM, Pavel Stehule wrote:
>>
>> this problem is little bit deeper and is related to plpgsql method for
>> SQL query processing.
>>
>> I thing so there are two solutions:
>>
>> a) use dynamic SQL
>> b) use double quotes for identifier - identifie
On Thu, May 21, 2009 at 12:21 AM, Josh Berkus wrote:
>> It appears that this statement has been in our documentation since Tom
>> Lane added FROM_COLLAPSE_LIMIT (back then, it was capitalized) on
>> January 25, 2003 (9bf97ff426de9), but I can't find any justification
>> for it anywhere. I think w
Robert,
It appears that this statement has been in our documentation since Tom
Lane added FROM_COLLAPSE_LIMIT (back then, it was capitalized) on
January 25, 2003 (9bf97ff426de9), but I can't find any justification
for it anywhere. I think we either need to justify this advice, or
remove it.
.
On Thu, May 21, 2009 at 12:04 AM, Fly.Li wrote:
> Reading libpq code( PQexec() ), I cann't find measure for thread safety.
>
> Read libpq doc, there are some words:
> -
> One thread restriction is that no two threads attempt to manipulate the same
> PGconn object at the same ti
We currently have a (really handy) facility to pull a message from the
archives by message-ID, eg:
http://archives.postgresql.org/message-id/603c8f070905202040v66cd3054t434c0b73aa844...@mail.gmail.com
Could we possibly get a similar type of link that pulls the raw
contents of the message, without
Hi, all
Reading libpq code( PQexec() ), I cann't find measure for thread safety.
Read libpq doc, there are some words:
-
One thread restriction is that no two threads attempt to manipulate the same
PGconn object at the same time. In particular, you cannot issue concurrent
co
The docs contain the following sage advice concerning from_collapse_limit:
"It is usually wise to keep this less than geqo_threshold."
I've been thinking through this advice on and off for about 2 years
and I still don't understand it. The point of either
from_collapse_limit and geqo_threshold i
Hi
Tobias Zahn escreveu:
Hello Adriano,
thank you very much for posting your patch. I think it will help to make
further work easier, too. I hope you don't mind when I ask you some
questions.
When you said that this new approach is worse or equal than GEQO, did
you refer to performance or to th
Simon Riggs píše v st 20. 05. 2009 v 09:14 +0100:
> >
> > What I heart is that standard malloc is not good, but it is still here
> > for compatibility reason with old application which depends on some
> > functionality.
>
> Which one is used in the default PostgreSQL build for Solaris? If you
>
On Saturday 16 May 2009 05:41:01 Euler Taveira de Oliveira wrote:
> While translating some pg_dump messages I noticed that some messages could
> be part of plural form. I attached a patch that catches those remaining
> messages.
Committed. Thanks.
--
Sent via pgsql-hackers mailing list (pgsql-h
On Wednesday 20 May 2009 16:24:21 Tom Lane wrote:
> Heikki Linnakangas writes:
> > Hmm, it is a false alarm, but would be nice to have a warning-free
> > build. I don't see that warning here on gcc 4.3.3 by default, but I do
> > when I set -Wformat-security. I presume you had that set as well.
>
>
On Sunday 26 April 2009 21:29:20 Tom Lane wrote:
> ereport(msglevel,
> /* translator: %d always has a value larger than 1 */
> (errmsg(ngettext("drop cascades to %d other object",
> "drop cascades to %d other objects",
>
On May 20, 2009, at 10:24 AM, Pavel Stehule wrote:
this problem is little bit deeper and is related to plpgsql method for
SQL query processing.
I thing so there are two solutions:
a) use dynamic SQL
b) use double quotes for identifier - identifiers have to be lower
t := fun1(a as "a");
plpgs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wearing the PGCon 2009 t-shirt
http://img199.imageshack.us/my.php?image=b9w.jpg&via=tfrog
- --
Dan Langille
BSDCan - The Technical BSD Conference : http://www.bsdcan.org/
PGCon - The PostgreSQL Conference: http://www.pgcon.org/
-BE
so solution is simple
as two lines to genbki.sh - there is similar jobs - NameData => name, ...
regards
Pavel Stehule
2009/5/20 Alvaro Herrera :
> Tom Lane escribió:
>> Alvaro Herrera writes:
>> > Pavel Stehule escribió:
>> >> Initdb finish with bug unrecognized type "TimestampTz", because
>> >
Tom Lane escribió:
> Alvaro Herrera writes:
> > Pavel Stehule escribi�:
> >> Initdb finish with bug unrecognized type "TimestampTz", because
> >> pg_type knows "timestamptz". But I can't to use timestamptz, because
> >> the identifier is "TimestampTz".
>
> > See pg_authid.h ... is that not enough
On Wed, 2009-05-20 at 16:03 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > 2. shmem_startup_hook doesn't allow multiple modules to create shmem.
> > All callers of the hook think they are the only caller, causing chaos if
> > multiple people need this.
>
> The only known caller, contrib/pg_sta
Simon Riggs writes:
> 2. shmem_startup_hook doesn't allow multiple modules to create shmem.
> All callers of the hook think they are the only caller, causing chaos if
> multiple people need this.
The only known caller, contrib/pg_stat_statements/, does not think that.
Do what it does.
I agree it
2009/5/20 Tom Lane :
> Alvaro Herrera writes:
>> Pavel Stehule escribió:
>>> Initdb finish with bug unrecognized type "TimestampTz", because
>>> pg_type knows "timestamptz". But I can't to use timestamptz, because
>>> the identifier is "TimestampTz".
>
>> See pg_authid.h ... is that not enough?
>
Alvaro Herrera writes:
> Pavel Stehule escribió:
>> Initdb finish with bug unrecognized type "TimestampTz", because
>> pg_type knows "timestamptz". But I can't to use timestamptz, because
>> the identifier is "TimestampTz".
> See pg_authid.h ... is that not enough?
That was okay for a one-off ha
2009/5/20 Alvaro Herrera :
> Pavel Stehule escribió:
>> Hello
>>
>> I have a problem with creating bootstrap table with TimestampTz type.
>>
>> Initdb finish with bug unrecognized type "TimestampTz", because
>> pg_type knows "timestamptz". But I can't to use timestamptz, because
>> the identifier i
Hi,
Le 20 mai 09 à 20:51, Simon Riggs a écrit :
1. Want some very clear and supported way to know whether Postgres is
fully up. Currently, if you write _PG_init you sometimes need to
know if
it is being executed by LOAD or as a reload. So actual initialisation
sometimes needs to happen outsid
Pavel Stehule escribió:
> Hello
>
> I have a problem with creating bootstrap table with TimestampTz type.
>
> Initdb finish with bug unrecognized type "TimestampTz", because
> pg_type knows "timestamptz". But I can't to use timestamptz, because
> the identifier is "TimestampTz".
>
> What is good
Hello
I have a problem with creating bootstrap table with TimestampTz type.
Initdb finish with bug unrecognized type "TimestampTz", because
pg_type knows "timestamptz". But I can't to use timestamptz, because
the identifier is "TimestampTz".
What is good solution?
Thank You
Pavel
--
Sent via
Some feedback
1. Want some very clear and supported way to know whether Postgres is
fully up. Currently, if you write _PG_init you sometimes need to know if
it is being executed by LOAD or as a reload. So actual initialisation
sometimes needs to happen outside of _PG_init.
2. shmem_startup_hook
2009/5/20 Steve Prentice :
> t := fun1(1 as a); -- syntax error: "SELECT fun1(1 as $1 )"
>
> t := fun1(a as a); -- syntax error: "SELECT fun1( $1 as $1 )"
>
> On May 19, 2009, at 6:42 PM, Merlin Moncure wrote:
>
> you have a name conflict here...is it deliberate? I've l
t := fun1(1 as a); -- syntax error: "SELECT fun1(1 as
$1 )"
t := fun1(a as a); -- syntax error: "SELECT fun1( $1
as $1 )"
On May 19, 2009, at 6:42 PM, Merlin Moncure wrote:
you have a name conflict here...is it deliberate? I've learned the
hard way to always, alw
Hi,
Le 4 mai 09 à 14:24, Peter Eisentraut a écrit :
There aren't a lot of people who have the experience to write that
documentation. So if you want to improve it, you will have to write
it, or at
least organize the outline. Others can help cleaning it up.
For the record, here's the curre
Hello Adriano,
thank you very much for posting your patch. I think it will help to make
further work easier, too. I hope you don't mind when I ask you some
questions.
When you said that this new approach is worse or equal than GEQO, did
you refer to performance or to the quality of results?
Why do
>>> So at least transiently we use 3x the size of the actual array.
>> I was conjecturing, prior to investigation. Are you saying you know
>> this/have seen this already?
> Well I'm just saying if you realloc a x kilobyte block into a 2x block and
> the allocator can't expand it and has to copy t
Heikki Linnakangas writes:
> Hmm, it is a false alarm, but would be nice to have a warning-free
> build. I don't see that warning here on gcc 4.3.3 by default, but I do
> when I set -Wformat-security. I presume you had that set as well.
Would it be worth having configure probe for that switch a
On Wed, May 20, 2009 at 6:34 AM, Stefan Keller wrote:
> Questions: Don't see, why this would be a security issue: How could such a
> function do any harm? large files?
No, large files aren't the problem. The problem is that the
PostgreSQL server process may have rights to access things that the
Tom,
> Apparently you've not found pg_read_file() ?
Thanks a lot. Did'nt find this. This helped!
Still, get_url() would be handy too... :->
Questions: Don't see, why this would be a security issue: How could such a
function do any harm? large files?
Finally: Got some tricky followup questions r
Fujii Masao wrote:
I encountered the following compiler warning in 8.4dev.
Attached is the patch to fix this problem. Is this worth committing?
--
tablecmds.c: In function 'DropErrorMsgWrongType':
tablecmds.c:606: warning: format not a string literal and no format arguments
-
On 05/20/2009 10:14 AM, Simon Riggs wrote:
On Tue, 2009-05-19 at 22:19 +0200, Zdenek Kotala wrote:
Chuck McDevitt píše v út 19. 05. 2009 v 09:33 -0700:
What I heart is that standard malloc is not good, but it is still here
for compatibility reason with old application which depends on some
funct
On Tue, 2009-05-19 at 16:49 -0400, Greg Stark wrote:
> Well I'm just saying if you realloc a x kilobyte block into a 2x block
> and the allocator can't expand it and has to copy then it seems
> inevitable.
OK, understood.
So there is grounds at least for an investigation into how that works
On Tue, 2009-05-19 at 22:19 +0200, Zdenek Kotala wrote:
> Chuck McDevitt píše v út 19. 05. 2009 v 09:33 -0700:
> > Solaris default malloc always uses sbrk(), and never ever tried to reduce
> > the sbrk point.
> >
> > If you want a malloc that uses mmap, there is an non-default malloc that
> >
38 matches
Mail list logo
