[PATCHES] Minor verbosity increase for analyze
Attached is a (very small) patch to make analyze display some interesting info in verbose mode about the analyzed relation (pages, rows per block and rows ). This is all available in the statistics catalog but I have found it useful to see it appear as you run... mods to : src/backend/commands/analyze.c plain diff against current CVS (31/07/2003 NZST) Best wishes Mark 696a697,702 /* * emit some interesting relation info */ elog(elevel, pages = %d rows/page = %d rows = %d, onerel-rd_nblocks, (int)tuplesperpage, (int)*totalrows); ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[PATCHES] Check for failed memory allocations in libpq
Attached is a patch (against 7.3.4) to check the return values of some
calls (malloc, realloc, etc.) for failed memory allocations in libpq.
--
Dave Allen
[EMAIL PROTECTED]
--- postgresql-7.3.4-orig/src/interfaces/libpq/fe-exec.cWed Sep 4 13:31:47
2002
+++ postgresql-7.3.4/src/interfaces/libpq/fe-exec.c Wed Jul 30 16:04:20 2003
@@ -365,6 +365,8 @@
PGresult *result;
result = (PGresult *) malloc(sizeof(PGresult));
+ if (result == NULL)
+ return NULL;
result-xconn = conn; /* might be NULL */
result-ntups = 0;
@@ -966,8 +968,12 @@
if (pqGets(conn-workBuffer, conn))
return;
if (conn-result == NULL)
+ {
conn-result =
PQmakeEmptyPGresult(conn,
PGRES_COMMAND_OK);
+ if (conn-result == NULL)
+ return;
+ }
strncpy(conn-result-cmdStatus,
conn-workBuffer.data,
CMDSTATUS_LEN);
conn-asyncStatus = PGASYNC_READY;
@@ -994,8 +1000,12 @@
DONOTICE(conn, noticeWorkspace);
}
if (conn-result == NULL)
+ {
conn-result =
PQmakeEmptyPGresult(conn,
PGRES_EMPTY_QUERY);
+ if (conn-result == NULL)
+ return;
+ }
conn-asyncStatus = PGASYNC_READY;
break;
case 'K': /* secret key data from the
backend */
@@ -1113,6 +1123,8 @@
int i;
result = PQmakeEmptyPGresult(conn, PGRES_TUPLES_OK);
+ if (result == NULL)
+ return EOF;
/* parseInput already read the 'T' label. */
/* the next two bytes are the number of fields */
@@ -1128,6 +1140,11 @@
{
result-attDescs = (PGresAttDesc *)
pqResultAlloc(result, nfields * sizeof(PGresAttDesc), TRUE);
+ if (result-attDescs == NULL)
+ {
+ PQclear(result);
+ return EOF;
+ }
MemSet((char *) result-attDescs, 0, nfields * sizeof(PGresAttDesc));
}
@@ -1209,7 +1226,11 @@
nbytes = (nfields + BYTELEN - 1) / BYTELEN;
/* malloc() only for unusually large field counts... */
if (nbytes sizeof(std_bitmap))
+ {
bitmap = (char *) malloc(nbytes);
+ if (bitmap == NULL)
+ goto outOfMemory;
+ }
if (pqGetnchar(bitmap, nbytes, conn))
goto EOFexit;
@@ -1525,6 +1546,9 @@
*/
newNotify = (PGnotify *) malloc(sizeof(PGnotify) +
strlen(conn-workBuffer.data) +1);
+ if (newNotify == NULL)
+ return EOF;
+
newNotify-relname = (char *) newNotify + sizeof(PGnotify);
strcpy(newNotify-relname, conn-workBuffer.data);
newNotify-be_pid = be_pid;
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [PATCHES] Minor verbosity increase for analyze
After browsing this list, I thought I would re-submit this in a more standard form. In addition I corrected a couple of things (integer cast for the number of rows, and capitalization in the comment) regards Mark --- src/backend/commands/analyze.c.orig 2003-07-31 20:49:22.0 -0400 +++ src/backend/commands/analyze.c 2003-07-31 20:49:29.0 -0400 @@ -694,6 +694,12 @@ */ *totalrows = floor((double) onerel-rd_nblocks * tuplesperpage + 0.5); + /* +* Emit some interesting relation info +*/ + elog(elevel, pages = %d rows/page = %d rows = %.0f, + onerel-rd_nblocks, (int)tuplesperpage, *totalrows); + return numrows; } ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] ruleutils with pretty-print option
Tom Lane wrote: Applied with some editorializing. In particular, I don't believe the original did the right thing with (a - (b - c)). Oops, missed that case... But now, we have (a + ( b + c)) again. A patch that removes parentheses for + and * is appended. Regards, Andfdsa ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[Fwd: Re: [PATCHES] ruleutils with pretty-print option]
Now the patch is *really* appended :-) Tom Lane wrote: Applied with some editorializing. In particular, I don't believe the original did the right thing with (a - (b - c)). Oops, missed that case... But now, we have (a + ( b + c)) again. A patch that removes parentheses for + and * is appended. Regards, Andfdsa Index: backend/utils/adt/ruleutils.c === RCS file: /projects/cvsroot/pgsql-server/src/backend/utils/adt/ruleutils.c,v retrieving revision 1.147 diff -c -r1.147 ruleutils.c *** backend/utils/adt/ruleutils.c 30 Jul 2003 22:56:23 - 1.147 --- backend/utils/adt/ruleutils.c 31 Jul 2003 09:32:15 - *** *** 2547,2552 --- 2547,2559 if (node == (Node *) lfirst(((OpExpr *) parentNode)-args)) return true; + /* + * Exception: for * and +, ordering doesn't matter + */ + if ((*op == '+' *parentOp == '+') || + (*op == '*' *parentOp == '*')) + return true; + return false; } /* else do the same stuff as for T_SubLink et al. */ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [Fwd: Re: [PATCHES] ruleutils with pretty-print option]
Tom Lane wrote: Now the patch is *really* appended :-) And rejected. Ok, the ckeck for node being the first child already does the trick for standard l-t-r evaluation. You cannot assume that an operator is commutative or associative just because it has a name you think ought to be. (For a counter-example, it's well known that floating-point addition is not associative.) Well, to me it's not well-known that floating-point addition is not associative, do I need to re-learn my math? More: if the tree structure for ops of equal precedence looks like a + (b + c), then it's a near certainty that the user wrote those parentheses. Why would you think that removing them is pretty-printing? In this case the user really wrote the parentheses, so they should be shown. This stuff is all about guessing what the original definition looked like, if we just had the source sigh... I had a conversation with Bruce about embedded comments, and we found that the idea of (mis-)using nodes for this seems to be not viable. Still seeking for a way to preserve more-or-less the original user's definition. Regards, Andreas ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Check for failed memory allocations in libpq
Dave Allen [EMAIL PROTECTED] writes: Attached is a patch (against 7.3.4) to check the return values of some calls (malloc, realloc, etc.) for failed memory allocations in libpq. You sure you aren't just trading one misbehavior for another? The change in PQmakeEmptyPGresult, for example, just moves the core dump somewhere else, unless you find reasonable fallbacks for *all* its callers (including applications you don't have the source code for, but in any case including every one of the calls in libpq). regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] ruleutils with pretty-print option
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I didn't like the functions ending in _ext. I renamed them to _pp for pretty print. Patch attached and applied. Seems to be shy a catversion bump; since you have just made an incompatible change in the internal-function-names array, one is needed. But I disagree with your opinion anyway --- _ext for extended made perfect sense to me, especially for the get_indexdef one which adds more than just prettyprint functionality. OK. I never did the commit, so I will just discard the patch. Thanks. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [Fwd: Re: [PATCHES] ruleutils with pretty-print option]
Andreas Pflug [EMAIL PROTECTED] writes: Well, to me it's not well-known that floating-point addition is not associative, do I need to re-learn my math? regression=# select (1.0::float8 + (-1.0::float8)) + 1.0e-20::float8; ?column? -- 1e-20 (1 row) regression=# select 1.0::float8 + ((-1.0::float8) + 1.0e-20::float8); ?column? -- 0 (1 row) regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] ruleutils with pretty-print option
Would you send over the patch --- it was missing. --- Andreas Pflug wrote: Tom Lane wrote: Applied with some editorializing. In particular, I don't believe the original did the right thing with (a - (b - c)). Oops, missed that case... But now, we have (a + ( b + c)) again. A patch that removes parentheses for + and * is appended. Regards, Andfdsa ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] updateable cursors
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: This has been saved for the 7.5 release: http:/momjian.postgresql.org/cgi-bin/pgpatches2 Saved for? It's not gonna be acceptable in its current form for 7.5, either. I saved the patch plus your comments about it, so we can start on it again for 7.5. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] updateable cursors
Bruce Momjian [EMAIL PROTECTED] writes: This has been saved for the 7.5 release: http:/momjian.postgresql.org/cgi-bin/pgpatches2 Saved for? It's not gonna be acceptable in its current form for 7.5, either. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[PATCHES] preload libraries patch [was: [GENERAL] hexadecimal to decimal]
Tom Lane wrote:
It seems entirely sensible to me for the postmaster to choke on invalid
settings in postgresql.conf. Better than failing to mention the problem
at all, anyway.
2) do you want a patch that exports plperl_init_all() (and I guess
similar init functions in pltcl and plpython)?
Yeah, I guess. Might as well make one in plpgsql too --- even if it
does nothing today, it might be useful in the future, so the
documentation ought to recommend call 'plxxx_init' when preloading plxxx
as a general thing.
Attached is a patch that:
1) fixes the behavior of preload_libraries
2) adds an exported xxx_init() function to plperl, pltcl, plpython, and
plpgsql
3) updates the documentation for the changes
Compiles clean, and passes all regression tests with the following line
in postgresql.conf (this probably won't wrap nicely):
preload_libraries =
'$libdir/plperl:plperl_init,$libdir/pltcl:pltcl_init,$libdir/plpython:plpython_init,$libdir/plpgsql:plpgsql_init'
I ran the following both without (one psql session for all four
statements) and with preloading (also all four in one session). The
actual function definitions at the bottom of the email:
without preload:
=
regression=# explain analyze select echo_plperl('hello');
Total runtime: 55.29 msec
regression=# explain analyze select echo_pltcl('hello');
Total runtime: 23.34 msec
regression=# explain analyze select echo_plpythonu('hello');
Total runtime: 32.40 msec
regression=# explain analyze select echo_plpgsql('hello');
Total runtime: 3.09 msec
with preload:
=
regression=# explain analyze select echo_plperl('hello');
Total runtime: 5.14 msec
regression=# explain analyze select echo_pltcl('hello');
Total runtime: 7.64 msec
regression=# explain analyze select echo_plpythonu('hello');
Total runtime: 1.91 msec
regression=# explain analyze select echo_plpgsql('hello');
Total runtime: 1.35 msec
Please apply.
Thanks,
Joe
--test functions
CREATE OR REPLACE FUNCTION echo_plperl(text) RETURNS text AS '
return $_[0];
' LANGUAGE plperl;
CREATE OR REPLACE FUNCTION echo_pltcl(text) RETURNS text AS '
return $1
' LANGUAGE pltcl;
CREATE OR REPLACE FUNCTION echo_plpythonu(text) RETURNS text AS '
return args[0]
' LANGUAGE plpythonu;
CREATE OR REPLACE FUNCTION echo_plpgsql(text) RETURNS text AS '
begin
return $1;
end;
' LANGUAGE plpgsql;
explain analyze select echo_plperl('hello');
explain analyze select echo_pltcl('hello');
explain analyze select echo_plpythonu('hello');
explain analyze select echo_plpgsql('hello');
Index: doc/src/sgml/runtime.sgml
===
RCS file: /opt/src/cvs/pgsql-server/doc/src/sgml/runtime.sgml,v
retrieving revision 1.197
diff -c -r1.197 runtime.sgml
*** doc/src/sgml/runtime.sgml 29 Jul 2003 00:03:17 - 1.197
--- doc/src/sgml/runtime.sgml 31 Jul 2003 18:09:00 -
***
*** 1008,1032
can also be optionally specified by adding a colon followed by
the name of the initialization function after the library
name. For example
! literal'$libdir/mylib:init_mylib'/literal would cause
! literalmylib/ to be preloaded and literalinit_mylib/
to be executed. If more than one library is to be loaded, they
must be delimited with a comma.
/para
para
! If literalmylib/ is not found, the server will fail to
! start. However, if literalinit_mylib/ is not found,
! literalmylib/ will still be preloaded without executing
! the initialization function.
/para
para
By preloading a shared library (and initializing it if
applicable), the library startup time is avoided when the
library is first used. However, the time to start each new
! server process may increase, even if that process never
! uses the library.
/para
/listitem
/varlistentry
--- 1008,1037
can also be optionally specified by adding a colon followed by
the name of the initialization function after the library
name. For example
! literal'$libdir/mylib:mylib_init'/literal would cause
! literalmylib/ to be preloaded and literalmylib_init/
to be executed. If more than one library is to be loaded, they
must be delimited with a comma.
/para
para
! If literalmylib/ or literalmylib_init/ are not found, the
! server will fail to start.
!/para
!
!para
! PostgreSQL Procedural Language libraries may be preloaded in this way,
! typically by using the syntax literal'$libdir/plXXX:plXXX_init'
! /literal where literalXXX/literal is literalpgsql/,
! literalperl/, literaltcl/, or literalpython/.
/para
para
Re: [PATCHES] preload libraries patch [was: [GENERAL] hexadecimal to decimal]
Tom Lane wrote: As coded, this will cause pltcl to try to execute the unknown-module load on every pltcl function call :-(. You really need two bits of state if you are going to have separate postmaster-time and backend-time initialization. Hmmm, I see your point :(. Sorry about that! Will fix and commit. Thanks, Joe ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] Check for failed memory allocations in libpq
Apologies if I missed anything, but I thought I fixed any callers of PQmakeEmptyPQresult that weren't already checking (parseInput and getRowDescriptions were the only ones). I of course can't fix any applications I don't have the source for, but if I missed something in libpq, I'd be more than happy to go back and try to fix it. On Thu, 2003-07-31 at 07:05, Tom Lane wrote: Dave Allen [EMAIL PROTECTED] writes: Attached is a patch (against 7.3.4) to check the return values of some calls (malloc, realloc, etc.) for failed memory allocations in libpq. You sure you aren't just trading one misbehavior for another? The change in PQmakeEmptyPGresult, for example, just moves the core dump somewhere else, unless you find reasonable fallbacks for *all* its callers (including applications you don't have the source code for, but in any case including every one of the calls in libpq). regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html -- Dave Allen [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] Autoconf test for incompatible version of flex
[ followup to old message ] Greg Stark [EMAIL PROTECTED] writes: This patch adds an autoconf test to check for the new incompatible version of flex. Peter E. claims that CVS tip does work with flex 2.5.31 --- so we shouldn't need this patch anymore. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] Check for failed memory allocations in libpq
Dave Allen [EMAIL PROTECTED] writes: You sure you aren't just trading one misbehavior for another? Apologies if I missed anything, but I thought I fixed any callers of PQmakeEmptyPQresult that weren't already checking (parseInput and getRowDescriptions were the only ones). Well, I'm concerned about the global implications. For instance, I think making parseInput simply return on malloc failure *without doing any more* will convert out-of-memory from a core dump into an infinite loop; which is hardly an improvement. (See PQgetResult for one example of a place that will loop till it gets something.) I'd be the first to admit that libpq's error handling isn't very good, but I think fixing it will take some wholesale rework of the internal calling conventions, not a few lines of localized patches. Having said that, though, CVS tip does have some progress on this matter; it will usually behave reasonably when it runs out of memory for a query result. If you'd like to pursue the matter, please pull down CVS tip and see what you can do with it. The patch as given would not be much use to us anyway because of the changes since 7.3... regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
[PATCHES] Russian NLS Update: psql
Attached a complete translation of psql. -s psql-ru.zip psql-ru.zip Description: Zip compressed data ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[PATCHES] contrib regression test update
Quoting behavior changed in the message that produces, e.g.: NOTICE: type seg is not yet defined This patch updates all the contrib regression tests for the change. Please apply. Thanks, Joe Index: contrib/btree_gist/expected/btree_gist.out === RCS file: /opt/src/cvs/pgsql-server/contrib/btree_gist/expected/btree_gist.out,v retrieving revision 1.10 diff -c -r1.10 btree_gist.out *** contrib/btree_gist/expected/btree_gist.out 24 Jul 2003 17:52:11 - 1.10 --- contrib/btree_gist/expected/btree_gist.out 1 Aug 2003 02:36:47 - *** *** 3,24 -- does not depend on contents of btree_gist.sql. -- \set ECHO none ! psql:btree_gist.sql:8: NOTICE: type int2key is not yet defined DETAIL: Creating a shell type definition. psql:btree_gist.sql:13: NOTICE: argument type int2key is only a shell ! psql:btree_gist.sql:25: NOTICE: type int4key is not yet defined DETAIL: Creating a shell type definition. psql:btree_gist.sql:30: NOTICE: argument type int4key is only a shell ! psql:btree_gist.sql:42: NOTICE: type int8key is not yet defined DETAIL: Creating a shell type definition. psql:btree_gist.sql:47: NOTICE: argument type int8key is only a shell ! psql:btree_gist.sql:59: NOTICE: type float4key is not yet defined DETAIL: Creating a shell type definition. psql:btree_gist.sql:64: NOTICE: argument type float4key is only a shell ! psql:btree_gist.sql:77: NOTICE: type float8key is not yet defined DETAIL: Creating a shell type definition. psql:btree_gist.sql:82: NOTICE: argument type float8key is only a shell ! psql:btree_gist.sql:392: NOTICE: type tskey is not yet defined DETAIL: Creating a shell type definition. psql:btree_gist.sql:397: NOTICE: argument type tskey is only a shell CREATE TABLE int4tmp (b int4); --- 3,24 -- does not depend on contents of btree_gist.sql. -- \set ECHO none ! psql:btree_gist.sql:8: NOTICE: type int2key is not yet defined DETAIL: Creating a shell type definition. psql:btree_gist.sql:13: NOTICE: argument type int2key is only a shell ! psql:btree_gist.sql:25: NOTICE: type int4key is not yet defined DETAIL: Creating a shell type definition. psql:btree_gist.sql:30: NOTICE: argument type int4key is only a shell ! psql:btree_gist.sql:42: NOTICE: type int8key is not yet defined DETAIL: Creating a shell type definition. psql:btree_gist.sql:47: NOTICE: argument type int8key is only a shell ! psql:btree_gist.sql:59: NOTICE: type float4key is not yet defined DETAIL: Creating a shell type definition. psql:btree_gist.sql:64: NOTICE: argument type float4key is only a shell ! psql:btree_gist.sql:77: NOTICE: type float8key is not yet defined DETAIL: Creating a shell type definition. psql:btree_gist.sql:82: NOTICE: argument type float8key is only a shell ! psql:btree_gist.sql:392: NOTICE: type tskey is not yet defined DETAIL: Creating a shell type definition. psql:btree_gist.sql:397: NOTICE: argument type tskey is only a shell CREATE TABLE int4tmp (b int4); Index: contrib/cube/expected/cube.out === RCS file: /opt/src/cvs/pgsql-server/contrib/cube/expected/cube.out,v retrieving revision 1.12 diff -c -r1.12 cube.out *** contrib/cube/expected/cube.out 24 Jul 2003 17:52:15 - 1.12 --- contrib/cube/expected/cube.out 1 Aug 2003 02:36:49 - *** *** 6,12 -- does not depend on contents of cube.sql. -- \set ECHO none ! psql:cube.sql:10: NOTICE: type cube is not yet defined DETAIL: Creating a shell type definition. psql:cube.sql:15: NOTICE: argument type cube is only a shell -- --- 6,12 -- does not depend on contents of cube.sql. -- \set ECHO none ! psql:cube.sql:10: NOTICE: type cube is not yet defined DETAIL: Creating a shell type definition. psql:cube.sql:15: NOTICE: argument type cube is only a shell -- Index: contrib/earthdistance/expected/earthdistance.out === RCS file: /opt/src/cvs/contrib/earthdistance/expected/earthdistance.out,v retrieving revision 1.7 diff -c -r1.7 earthdistance.out *** contrib/earthdistance/expected/earthdistance.out24 Jul 2003 17:52:23 - 1.7 --- contrib/earthdistance/expected/earthdistance.out1 Aug 2003 02:36:51 - *** *** 6,12 -- does not depend on contents of earthdistance.sql or cube.sql. -- \set ECHO none ! psql:../cube/cube.sql:10: NOTICE: type cube is not yet defined DETAIL: Creating a shell type definition. psql:../cube/cube.sql:15: NOTICE: argument type cube is only a shell -- --- 6,12 -- does not depend on contents of earthdistance.sql or cube.sql. -- \set ECHO none ! psql:../cube/cube.sql:10: NOTICE: type cube is not yet defined DETAIL: Creating a shell type definition. psql:../cube/cube.sql:15: NOTICE: argument type cube is
