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
does that
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 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
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
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
On Wed, May 20, 2009 at 6:34 AM, Stefan Keller sfkel...@gmail.com 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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
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 then it
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, always
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
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
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
2009/5/20 Steve Prentice prent...@cisco.com:
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
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
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 solution?
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
2009/5/20 Alvaro Herrera alvhe...@commandprompt.com:
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
Alvaro Herrera alvhe...@commandprompt.com 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
2009/5/20 Tom Lane t...@sss.pgh.pa.us:
Alvaro Herrera alvhe...@commandprompt.com 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
Simon Riggs si...@2ndquadrant.com 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
On Wed, 2009-05-20 at 16:03 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com 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,
Tom Lane escribió:
Alvaro Herrera alvhe...@commandprompt.com 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
so solution is simple
as two lines to genbki.sh - there is similar jobs - NameData = name, ...
regards
Pavel Stehule
2009/5/20 Alvaro Herrera alvhe...@commandprompt.com:
Tom Lane escribió:
Alvaro Herrera alvhe...@commandprompt.com writes:
Pavel Stehule escribió:
Initdb finish with bug
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wearing the PGCon 2009 t-shirt
http://img199.imageshack.us/my.php?image=b9w.jpgvia=tfrog
- --
Dan Langille
BSDCan - The Technical BSD Conference : http://www.bsdcan.org/
PGCon - The PostgreSQL Conference: http://www.pgcon.org/
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);
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 Wednesday 20 May 2009 16:24:21 Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
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
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
use
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
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 is
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
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,
On Thu, May 21, 2009 at 12:04 AM, Fly.Li fly...@126.com 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
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:21 AM, Josh Berkus j...@agliodbs.com 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.
2009/5/21 Steve Prentice prent...@cisco.com:
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 -
37 matches
Mail list logo
