Re: [HACKERS] Multiple sorts in a query
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 (libumem or something?) There are severals memory allocator on Solaris. You can choose what you need. See mapalloc (it uses mmap insted of srbk) mtmalloc (optimized fro multi threaded apps) mumem_alloc watchmalloc bsdmalloc maybe more. 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 default malloc, have you tested the others and would you recommend one in particular? Which one has Dimitri used in his performance testing? -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Multiple sorts in a query
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 and whether it is as inefficient as we think it might be. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Multiple sorts in a query
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 functionality. Which one is used in the default PostgreSQL build for Solaris? If you use default malloc, have you tested the others and would you recommend one in particular? You don't even need to recompile it most of the time (unless statically compiled or similar things). LD_PRELOAD'ing another malloc library should normally be enough. Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Compiler warning
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 -- 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. Applied. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal: functions get_text() or get_url()
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 regarding index usage in
tsearch2 and regex. Should I place these here (or else where?)?
Regards, S.
2009/5/19 Tom Lane t...@sss.pgh.pa.us
Robert Haas robertmh...@gmail.com writes:
On Mon, May 18, 2009 at 4:03 PM, Stefan Keller sfkel...@gmail.com
wrote:
I'd expect functions like get_text() or get_url() in order to do the
following:
INSERT INTO collection(id, path, content) VALUES(1, '/tmp/mytext,
get_text('/tmp/mytext));
Apparently you've not found pg_read_file() ?
AFAIK there was a get_url in libcurl but I neither find it any more. But
anyway: This should be part of the core... :-
Putting this into core would have security implications. The file or
URL would be downloaded by the PostgreSQL server process, not the
client process - therefore I think it would have to be super-user
only, which would make it much less useful.
Yes. I very strongly doubt that we'd accept a url-fetching function at
all. Aside from the security issues, it would necessarily pull in a
boatload of dependencies that we'd prefer not to have.
Of course, you can write such a thing trivially in plperlu or several
other untrusted PLs, and include any security restrictions you see fit
while you're at it. I'm not seeing how a built-in function that would
have to impose one-size-fits-all security requirements would be an
improvement.
regards, tom lane
Re: [HACKERS] Proposal: functions get_text() or get_url()
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 things that the user doesn't. For a simple case, imagine that PostgreSQL is behind a firewall and the user is in front of the firewall, but there's a port open to permit access to PostgreSQL. Now imagine that there is a web server behind the firewall. The firewall blocks the user from accessing the web server directly, but the user can ask PostgreSQL to download the URLs for him. In that way, the user can bypass the firewall. (Consider for example Andrew Chernow's company, which has clients connecting to their database server from all over the Internet...) ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Compiler warning
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 configure probe for that switch and add it to CFLAGS if available? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: realloc overhead (was [HACKERS] Multiple sorts in a query)
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 seems inevitable. FYI the malloc()/realloc()/free() on FC4 causes memory fragmentation, and thus a long-term growth in process memory, under some circumstances. ?This, together with the power-of-two allocations in aset.c not accounting for malloc() overhead (not that they could), implies that memory contexts can cause fragmentation, more slowly, too. Reallocations of smallish blocks from memory contexts tend to use memory already withheld from the OS; a transient increase in memory usage is possible, but unlikely to matter. ?Perhaps something should be done about larger blocks. David Hudson
Re: [HACKERS] plpgsql + named parameters
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 prefix arguments and locals to plpgsql functions with '_'. Or are you trying to do something fancier? The conflict is deliberate to illustrate the limitations the named parameter feature (on the list for the first 8.5 CommitFest) is going to have if parameter substitution is not addressed at the same time. -Steve
Re: [HACKERS] Documentation: GiST extension implementation
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 current version of the documentation patch, which still needs those items to be worked out: - patch format - proper English review - consistent signature update for 8.4 (recheck arg) - compress/decompress non void example - multi column support in picksplit I intend to try and work out those points, but it's all about areas I don't (yet) know about. Of course I won't complete the second point myself. Regards, -- dim gist.sgml.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Feedback on writing extensible modules
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 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. Currently, whoever sets up the hook gets to create shmem. (There's no docs for this yet). Would prefer something like RequestAddinShmemSpace() which can be called by multiple callers. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] GEQO: ERX
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 you think that compressed annealing might be the better approach?
TIA and best regards,
Tobias Zahn
Adriano Lange schrieb:
Robert Haas escreveu:
On Wed, May 13, 2009 at 4:14 PM, Tobias Zahn tobias-z...@arcor.de
wrote:
Hello,
thank you for posting the paper, it was quite interesting to read. I
think it would be a good idea to give the two-phase optimization a try.
As far as I know and understand the current (geqo) optimizer source,
many important parts are already there. For example, we can calculate
the costs of a given join order. Therefore, it would only be necessary
to write an algorithm witch chooses the right input for the cost
function.
I would be interested in your opinion.
I'm very interested in any improvements we can make to planning large
join nests. Unfortunately the paper seems to conclude that it's not
really feasible to use heuristics, as had been my hope, but I'd be
very interested in any other approaches we can come up with. I
probably do not have time to implement anything myself, but I'm happy
to help with ideas and code review.
I implemented the 2PO algorithm last month but I didn't have much time
to do an extensive test and to comment all code. The code was posted in
this list in a previous thread. In that occasion, I was interested in a
kind of cache structure to avoid the constructing a complete RelOptInfo
from scratch every time when the cheapest total_cost must be calculated
(this occur in GEQO).
I’m sending a patch for the 8.3 release.
I also changed some GUC variables to facilitate some tests:
(remove) geqo
(remove) geqo_threshold
(add) ljqo_enable (bool) – activate Large Join Query Optimizer
(add) ljqo_algorithm {geqo|twopo}
(add) ljqo_threshold (int) – like geqo_threshold
(add) twopo_heuristic_states (bool) – initial heuristic states
(add) twopo_ii_stop (int) – II phase loop
(add) twopo_sa_phase (bool) – enable SA phase
(add) twopo_sa_initial_temperature (float)
(add) twopo_sa_temperature_reduction (float)
(add) twopo_sa_equilibrium (int)
In my little tests, this algorithm seems equal or worse than geqo,
except when using heuristic in order to bias the initial state. Maybe
some tunings are needed but I prefer spend yet some time reading more
about the compressed annealing, cited in TODO list. Anyway, I think that
to build another annealing-like algorithm might be easier if some
structures and functions in 2PO source code are correct.
Sincerely,
Adriano Lange
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] plpgsql + named parameters
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 deliberate? I've learned the hard way to always, always prefix arguments and locals to plpgsql functions with '_'. Or are you trying to do something fancier? The conflict is deliberate to illustrate the limitations the named parameter feature (on the list for the first 8.5 CommitFest) is going to have if parameter substitution is not addressed at the same time. -Steve 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); regards Pavel Stehule -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] bootstrap table with TimestampTz type
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 pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] bootstrap table with TimestampTz type
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? See pg_authid.h ... is that not enough? -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Feedback on writing extensible modules
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 outside of _PG_init. And currently calling SPI_connect() from _PG_init will crash the backend. I'll try to obtain a gdb backtrace, I've just been told about pre_auth_delay and post_auth_delay parameters. Regards, -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] bootstrap table with TimestampTz type
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 identifier is TimestampTz. What is good solution? See pg_authid.h ... is that not enough? thank you, it'is it regards Pavel -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] bootstrap table with TimestampTz type
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 a one-off hack, but if we're going to have timestamptz in multiple catalogs, it might be nice to have a cleaner solution. Should we make it work like aclitem does (cf genbki.h)? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] bootstrap table with TimestampTz type
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 ... is that not enough? That was okay for a one-off hack, but if we're going to have timestamptz in multiple catalogs, it might be nice to have a cleaner solution. Should we make it work like aclitem does (cf genbki.h)? I found, so it was bad shot - In my case is timestamp field not null I'll look on genbki thank you Pavel regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Feedback on writing extensible modules
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 it does. I agree it's undocumented, but so are the other hooks ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Feedback on writing extensible modules
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, contrib/pg_stat_statements/, does not think that. Do what it does. Hmmm, it works, I guess. As long as everyone does that. Thanks for the workaround. I agree it's undocumented, but so are the other hooks ... Some are well documented in the code, not all though. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] bootstrap table with TimestampTz type
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 enough? That was okay for a one-off hack, but if we're going to have timestamptz in multiple catalogs, it might be nice to have a cleaner solution. Should we make it work like aclitem does (cf genbki.h)? Yeah, eventually we're going to need timestamps in autovacuum scheduler catalogs too, so if it's solved for good, all the better. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] bootstrap table with TimestampTz type
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 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 hack, but if we're going to have timestamptz in multiple catalogs, it might be nice to have a cleaner solution. Should we make it work like aclitem does (cf genbki.h)? Yeah, eventually we're going to need timestamps in autovacuum scheduler catalogs too, so if it's solved for good, all the better. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] PGCon 2009 t-shirt
-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/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoUk/8ACgkQCgsXFM/7nTxmLgCaAjTl9jI+8YdPS3LH7+9+bXQM 3FkAnRfHrmXGFwE89KLpnbq+AauxcQfk =4Z9f -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] plpgsql + named parameters
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);
plpgsql substitutes an expression parameter for the double-quoted
identifier as well and I'm less than thrilled about using dynamic SQL
to make all my function calls. I was hoping we could modify the
grammar so that identifiers after the AS keyword are passed through.
Something like this patch:
diff --git a/src/pl/plpgsql/src/gram.y b/src/pl/plpgsql/src/gram.y
index 06704cf..66d12d8 100644
--- a/src/pl/plpgsql/src/gram.y
+++ b/src/pl/plpgsql/src/gram.y
@@ -177,6 +177,7 @@ static List
*read_raise_options(void);
* Keyword tokens
*/
%token K_ALIAS
+%token K_AS
%token K_ASSIGN
%token K_BEGIN
%token K_BY
@@ -1977,6 +1978,7 @@ read_sql_construct(int until,
int *endtoken)
{
int tok;
+ int prevtok = 0;
int lno;
PLpgSQL_dstring ds;
int parenlevel = 0;
@@ -1989,7 +1991,7 @@ read_sql_construct(int until,
plpgsql_dstring_init(ds);
plpgsql_dstring_append(ds, sqlstart);
- for (;;)
+ for (;;prevtok = tok)
{
tok = yylex();
if (tok == until parenlevel == 0)
@@ -2034,10 +2036,22 @@ read_sql_construct(int until,
switch (tok)
{
case T_SCALAR:
- snprintf(buf, sizeof(buf), $%d ,
-
assign_expr_param(yylval.scalar-dno,
-
params, nparams));
- plpgsql_dstring_append(ds, buf);
+ /*
+* If the previous token is AS, then we pass
the scalar
+* through as a label. Otherwise, make the
scalar an
+* expression parameter.
+*/
+ if (prevtok == K_AS)
+ {
+ plpgsql_dstring_append(ds, yytext);
+ }
+ else
+ {
+ snprintf(buf, sizeof(buf), $%d ,
+
assign_expr_param(yylval.scalar-dno,
+
params, nparams));
+ plpgsql_dstring_append(ds, buf);
+ }
break;
case T_ROW:
diff --git a/src/pl/plpgsql/src/scan.l b/src/pl/plpgsql/src/scan.l
index 1917eef..e3a5c45 100644
--- a/src/pl/plpgsql/src/scan.l
+++ b/src/pl/plpgsql/src/scan.l
@@ -149,6 +149,7 @@ param \${digit}+
= { return K_ASSIGN; }
\.\.{ return K_DOTDOT; }
alias { return K_ALIAS; }
+as { return K_AS; }
begin { return K_BEGIN; }
by { return K_BY; }
case{ return K_CASE;}
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] A couple of gripes about the gettext plurals patch
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, numReportedClient + numNotReportedClient), numReportedClient + numNotReportedClient), This is bogus: errmsg expects that it should itself feed its first argument through gettext(), not receive an argument that is already translated. That's at the least a waste of cycles, and it's not entirely impossible that double translation could end up with a just plain wrong result. I think we can live with this for now, and we have lived with this sort of issue in other places for a while. We should consider reshuffling the interfaces a bit as you describe to reduce the problem. But I think this is not something we always avoid completely. I'm also wondering whether PGAC_CHECK_GETTEXT() should be made to check for ngettext() instead of bind_textdomain_codeset(). Which one was added later? I checked this in the gettext changelog, and bind_textdomain_code() came (slightly) later, so we're OK. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Compiler warning
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 you had that set as well. Would it be worth having configure probe for that switch and add it to CFLAGS if available? Note that applying this patch would introduce a double-translation issue of the sort that you had complained about a while ago. I'm unsure which way to proceed here. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] some more plural messages
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-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Multiple sorts in a query
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 default malloc, have you tested the others and would you recommend one in particular? 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. Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] GEQO: ERX
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 quality of results? Not exactly this approach, but the implemented (and not configured) algorithm was worse than GEQO in a little test made. I just used a sequence of 8 executions of a query with 18 relations for each algorithm. The costs generated by GEQO was little better than 2PO, in average and standard deviation. But 8 executions and 1 query don't prove anything. I want to make some further tests, but this little difference seems good for me. Why do you think that compressed annealing might be the better approach? I don't think if compressed annealing is better or not. I don't read about it yet. However, an optimizer can be better in a context but worse in another. Regards, Adriano -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] from_collapse_limit vs. geqo_threshold
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 to avoid exponential growth in planning time when planning large join nests. Either of them has the effect of reducing planning time at the expense of possibly getting an inferior plan. However, it's my experience that the plans that result when the from_collapse_limit kicks in are almost invariably terrible when fetching only a small number of rows. On the other hand, the few GEQO plans I've had experience with have been pretty reasonable. 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. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] How to issure PQexec is thread safety if use a connceion in two threads?
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 commands from different threads through the same connection object. (If you need to run concurrent commands, use multiple connections.) --- I dont't think it is a good idea. Should libpq do something for issure the true thread safety? ODBC specilization said: --- On multithread operating systems, drivers must be thread-safe. That is, it must be possible for applications to use the same handle on more than one thread. How this is achieved is driver-specific, and it is likely that drivers will serialize any attempts to concurrently use the same handle on two different threads. Applications commonly use multiple threads instead of asynchronous processing. The application creates a separate thread, calls an ODBC function on it, and then continues processing on the main thread. Rather than having to continually poll the asynchronous function, as is the case when the SQL_ATTR_ASYNC_ENABLE statement attribute is used, the application can simply let the newly created thread finish. Functions that accept a statement handle and are running on one thread can be canceled by calling SQLCancel with the same statement handle from another thread. Although drivers should not serialize the use of SQLCancel in this manner, there is no guarantee that calling SQLCancel will actually cancel the function running on the other thread. Any ideas? thanks regards Fly.Li -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] pull raw text of a message by message-id
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 any HTML markup? This would be useful when (for example) a message contains a patch that is included inline rather than as an attachment, and would also be useful for tool-building (e.g. given a message-ID, download the patch and attempt to apply it to my local working copy). ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] How to issure PQexec is thread safety if use a connceion in two threads?
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 the same time. In particular, you cannot issue concurrent commands from different threads through the same connection object. (If you need to run concurrent commands, use multiple connections.) --- I dont't think it is a good idea. Should libpq do something for issure the true thread safety? Well, I think the only thing we could really do is serialize access to the underlying connection object, since the backend can only execute one query at a time regardless of what libpq does. That would require some sort of synchronization overhead that would in most cases be wasted. If someone wants to implement an ODBC layer on top of libpq, they can protect access to the libpq connection object using a mutex at that level, which would solve the problem you're concerned about without imposing an unnecessary overhead on people using libpq directly from single-threaded applications. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] from_collapse_limit vs. geqo_threshold
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. ... trying to remember why I wrote that ... what would happen if FROM_COLLAPSE_LIMIT was *more* than GEQO_THRESHOLD? -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] from_collapse_limit vs. geqo_threshold
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. I think we either need to justify this advice, or remove it. ... trying to remember why I wrote that ... what would happen if FROM_COLLAPSE_LIMIT was *more* than GEQO_THRESHOLD? The two variables do different things, so there's nothing particularly magical about which one is larger AFAICS. I believe that if you make from_collapse_limit larger than geqo_threshold, then GEQO might be asked to plan a query into which subqueries have been pulled up. But that's not obviously bad; the alternative is planning the subquery separately and first, which at least for the very small number of cases that I've tested seems to be quite a bit worse. Apparently before from_collapse_limit was added the behavior existed, but the thereshold was geqo_threshold/2. So someone had a reason for believing that when the join nest got too large, not pulling up subqueries was a superior coping strategy versus invoking GEQO. I just don't know what the reason is, or whether it's still valid. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] plpgsql + named parameters
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 - identifiers have to be lower
t := fun1(a as a);
plpgsql substitutes an expression parameter for the double-quoted identifier
as well and I'm less than thrilled about using dynamic SQL to make all my
function calls. I was hoping we could modify the grammar so that identifiers
after the AS keyword are passed through.
Something like this patch:
diff --git a/src/pl/plpgsql/src/gram.y b/src/pl/plpgsql/src/gram.y
index 06704cf..66d12d8 100644
--- a/src/pl/plpgsql/src/gram.y
+++ b/src/pl/plpgsql/src/gram.y
@@ -177,6 +177,7 @@ static List
*read_raise_options(void);
* Keyword tokens
*/
%token K_ALIAS
+%token K_AS
%token K_ASSIGN
%token K_BEGIN
%token K_BY
@@ -1977,6 +1978,7 @@ read_sql_construct(int until,
int *endtoken)
{
int tok;
+ int prevtok = 0;
int lno;
PLpgSQL_dstring ds;
int parenlevel = 0;
@@ -1989,7 +1991,7 @@ read_sql_construct(int until,
plpgsql_dstring_init(ds);
plpgsql_dstring_append(ds, sqlstart);
- for (;;)
+ for (;;prevtok = tok)
{
tok = yylex();
if (tok == until parenlevel == 0)
@@ -2034,10 +2036,22 @@ read_sql_construct(int until,
switch (tok)
{
case T_SCALAR:
- snprintf(buf, sizeof(buf), $%d ,
-
assign_expr_param(yylval.scalar-dno,
-
params, nparams));
- plpgsql_dstring_append(ds, buf);
+ /*
+ * If the previous token is AS, then we pass
the scalar
+ * through as a label. Otherwise, make the
scalar an
+ * expression parameter.
+ */
+ if (prevtok == K_AS)
+ {
+ plpgsql_dstring_append(ds, yytext);
+ }
+ else
+ {
+ snprintf(buf, sizeof(buf), $%d ,
+
assign_expr_param(yylval.scalar-dno,
+
params, nparams));
+ plpgsql_dstring_append(ds, buf);
+ }
break;
case T_ROW:
diff --git a/src/pl/plpgsql/src/scan.l b/src/pl/plpgsql/src/scan.l
index 1917eef..e3a5c45 100644
--- a/src/pl/plpgsql/src/scan.l
+++ b/src/pl/plpgsql/src/scan.l
@@ -149,6 +149,7 @@ param \${digit}+
= { return K_ASSIGN; }
\.\. { return K_DOTDOT; }
alias { return K_ALIAS; }
+as { return K_AS; }
begin { return K_BEGIN; }
by { return K_BY; }
case { return K_CASE; }
+1
please append your patch to commitfest page
Pavel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
