Re: [PATCHES] [BUGS] BUG #1707: statistics collector starts with stats_start_collector
Alvaro Herrera [EMAIL PROTECTED] writes: What about arranging postmaster's main loop so that it starts the stats collector process if one of the options is activated (assuming they were all off at start)? Right now you have to restart the server, but I don't see why it has to be like that. The reason for a restart is that what stats_start_collector is REALLY all about is telling the postmaster whether to establish the loopback UDP socket for stats messaging. You don't get to add that after the fact because there'd be no way to propagate the open socket into existing backends. And no, I wouldn't look with favor on the idea of creating the socket unconditionally. One of the reasons for wanting to be able to turn off pgstats entirely is so that you aren't dead in the water if the loopback UDP socket won't work for some reason (example: kernel packet filtering that's not under your control). regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [PATCH] fix for pg_stat_database (numbackends is always
Petr Jelinek wrote: This patch fixes pg_stat_database which is broken since this commit: http://archives.postgresql.org/pgsql-committers/2005-05/msg00126.php Neilc forgot to add new db entry inicialization to pgstat_recv_bestart() when he removed it from pgstat_add_backend() function, which causes numbackends in pg_stat_database table to be allways zero. This is my first patch for postgres so I hope I did it right. Please ignore this email - it was sent when I wasn't subscribed and we already had discrussion here about this prob. -- Regards Petr Jelinek (PJMODOS)
Re: [PATCHES] Users/Groups - Roles
Stephen Frost [EMAIL PROTECTED] writes: Attached please find files and patches associated with moving from the User/Group system currently in place to Roles, as discussed previously. I have cleaned this up a bit and committed it. I normally wouldn't commit an incomplete patch, but this change is blocking Alvaro's work on dependencies for shared objects, so I felt it was best to get the catalog changes in now. That will let Alvaro work on dependencies while I sort out the unfinished bits of roles, which I intend to do over the next day or so. Many thanks for your work on this! regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [BUGS] BUG #1707: statistics collector starts with stats_start_collector
Tom Lane wrote: Actually, this entire thread is based on a misconception: the bug reporter was under the misimpression that the sum total of what the collector does is described by the three suboptions, and so having start_collector on without any of the suboptions on is a useless state. But this is not so. The collector tracks backend start/end in any case, and so you get a useful list of sessions in pg_stat_activity even without enabling any of the more expensive reporting options. Right. So my vote at this point is that the code is not broken and we should not change it. Possibly the documentation could stand a little improvement. No question. Alvaro Herrera [EMAIL PROTECTED] writes: What about arranging postmaster's main loop so that it starts the stats collector process if one of the options is activated (assuming they were all off at start)? Right now you have to restart the server, but I don't see why it has to be like that. The reason for a restart is that what stats_start_collector is REALLY all about is telling the postmaster whether to establish the loopback UDP socket for stats messaging. You don't get to add that after the fact because there'd be no way to propagate the open socket into existing backends. And no, I wouldn't look with favor on the idea of creating the socket unconditionally. One of the reasons for wanting to be able to turn off pgstats entirely is so that you aren't dead in the water if the loopback UDP socket won't work for some reason (example: kernel packet filtering that's not under your control). My issue is that we usually don't have GUC variables that can be set automatically. Why can't we have the stats collector try to start, and just throw a server log message if it fails. I guess I don't see why that is worse than a GUC. Why is the stats collector unique in its use of of the UDP resource? If we can't start IPv6 we just throw a server log message and contiue, right? -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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/faq
[PATCHES] per user/database connections limit again
Hi,
I attached second try of per-database and per-user connection limit for
your review.
This time I am using information stored in ProcArray to get number of
connections - I modified PGPROC struct to also include userid.
Limits for user and database are stored in catalog tables. This aproach
led to implementation of universal ALTER DATABASE query (I followed
ALTER USER ad ALTER DATABASE ... RENAME implementatons). So queries for
setting maximum connections look like this: CREATE|ALTER DATABASE|USER
name MAX CONNECTIONS = 20;
Maximum connections defaults to zero which means unlimited (limited by
global maximum only) and isn't enforced for superusers.
The actual check for maximum conenctions is done in ReverifyMyDatabase
for database and InitializeSessionUser for user because we don't have
information from system catalog before so we don't know how many
connections are allowed.
Patch includes only changes to backend, I will make pg_dump, ecpg and
documentation patches once this is completed and accepted by team.
Diff is made against cvs from today morning GMT (apply with -p1 if you
want to test it) - cvs is down now so I can't make diff against repository.
--
Regards
Petr Jelinek (PJMODOS)
diff -Nacr my-cvs/src/backend/commands/dbcommands.c
my-aproach2/src/backend/commands/dbcommands.c
*** my-cvs/src/backend/commands/dbcommands.cSun Jun 26 00:47:30 2005
--- my-aproach2/src/backend/commands/dbcommands.c Tue Jun 28 11:26:08 2005
***
*** 53,60
/* non-export function prototypes */
static bool get_db_info(const char *name, Oid *dbIdP, int4 *ownerIdP,
! int *encodingP, bool *dbIsTemplateP, bool *dbAllowConnP,
! Oid *dbLastSysOidP,
TransactionId *dbVacuumXidP, TransactionId
*dbFrozenXidP,
Oid *dbTablespace);
static bool have_createdb_privilege(void);
--- 53,60
/* non-export function prototypes */
static bool get_db_info(const char *name, Oid *dbIdP, int4 *ownerIdP,
! int *encodingP, int *dbMaxConnP, bool *dbIsTemplateP,
! bool *dbAllowConnP, Oid *dbLastSysOidP,
TransactionId *dbVacuumXidP, TransactionId
*dbFrozenXidP,
Oid *dbTablespace);
static bool have_createdb_privilege(void);
***
*** 74,79
--- 74,80
int src_encoding;
boolsrc_istemplate;
boolsrc_allowconn;
+ int src_maxconn;
Oid src_lastsysoid;
TransactionId src_vacuumxid;
TransactionId src_frozenxid;
***
*** 91,100
--- 92,103
DefElem*downer = NULL;
DefElem*dtemplate = NULL;
DefElem*dencoding = NULL;
+ DefElem*dmaxconn = NULL;
char *dbname = stmt-dbname;
char *dbowner = NULL;
const char *dbtemplate = NULL;
int encoding = -1;
+ int dbmaxconn = -1;
#ifndef WIN32
charbuf[2 * MAXPGPATH + 100];
***
*** 140,145
--- 143,156
errmsg(conflicting or
redundant options)));
dencoding = defel;
}
+ else if (strcmp(defel-defname, maxconnections) == 0)
+ {
+ if (dmaxconn)
+ ereport(ERROR,
+ (errcode(ERRCODE_SYNTAX_ERROR),
+errmsg(conflicting or
redundant options)));
+ dmaxconn = defel;
+ }
else if (strcmp(defel-defname, location) == 0)
{
ereport(WARNING,
***
*** 185,190
--- 196,203
elog(ERROR, unrecognized node type: %d,
nodeTag(dencoding-arg));
}
+ if (dmaxconn dmaxconn-arg)
+ dbmaxconn = intVal(dmaxconn-arg);
/* obtain sysid of proposed owner */
if (dbowner)
***
*** 218,224
* idea, so accept possibility of race to create. We will check again
* after we grab the exclusive lock.
*/
! if (get_db_info(dbname, NULL, NULL, NULL,
NULL, NULL, NULL, NULL, NULL, NULL))
ereport(ERROR,
(errcode(ERRCODE_DUPLICATE_DATABASE),
--- 231,237
* idea, so accept possibility of race to create. We will check again
* after we grab the exclusive lock.
*/
! if (get_db_info(dbname, NULL, NULL, NULL, NULL,
NULL, NULL, NULL, NULL, NULL, NULL))
ereport(ERROR,
Re: [PATCHES] COPY FROM performance improvements
Luke, Alon OK, I'm going to apply the patch to my copy and try to get my head around it. meanwhile: . we should not be describing things as old or new. The person reading the code might have no knowledge of the history, and should not need to. . we should not have slow and fast either. We should have text, csv and binary. IOW, the patch comments look slightly like it is intended for after the fact application rather than incorporation into the main code. Are you looking at putting CSV mode into the fast code? Please let me know if you have questions about that. There are only a few days left to whip this into shape. cheers andrew Luke Lonergan wrote: Andrew, Something strange has happened. I suspect that you've inadvertantly used GNU indent or an unpatched BSD indent. pgindent needs a special patched BSD indent to work according to the PG standards - see the README OK - phew! I generated new symbols for pgindent and fixed a bug in the awk scripting within (diff attached) and ran against the CVS tip copy.c and got only minor changes in formatting that appear to be consistent with the rest of the code. I pgindent'ed the COPY FROM performance modded code and it looks good and tests good. Only formatting changes to the previous patch for copy.c attached. Patch to update pgindent with new symbols and fix a bug in an awk section (extra \\ in front of a ')'). - Luke ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] regexp_replace
Bruce Momjian wrote: Andrew Dunstan wrote: I'm very glad to see this. But is a nicer name possible? To perl programmers at least, substitute should make sense. What is the matter with replace? We already have replace: test= \df replace List of functions Schema | Name | Result data type | Argument data types +-+--+- pg_catalog | replace | text | text, text, text I think that regexp_replace is a good name. It is easy to understand. regards, --- Atsushi Ogawa ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] regexp_replace
Atsushi Ogawa wrote: I think that regexp_replace is a good name. It is easy to understand. I'll go with the flow. cheers andrew ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] [BUGS] BUG #1707: statistics collector starts with stats_start_collector
Bruce Momjian pgman@candle.pha.pa.us writes: My issue is that we usually don't have GUC variables that can be set automatically. Why can't we have the stats collector try to start, and just throw a server log message if it fails. I still say the code is not broken and does not require fixing. If someone doesn't want any stats collection service, they shouldn't have to pay the overhead of having the collector there. That was the original design intention for pgstats, and there isn't anyone except you suggesting that we should force people to have the stats collector enabled. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
[PATCHES] Fwd: Re: [PERFORM] Performance analysis of plpgsql code [EMAIL PROTECTED]
On 06/27/2005 10:03:06 PM, Karl O. Pinc wrote: On 06/27/2005 08:34:19 PM, Michael Fuhr wrote: On Tue, Jun 28, 2005 at 01:54:08AM +, Karl O. Pinc wrote: On 06/27/2005 06:33:03 PM, Michael Fuhr wrote: See timeofday(). That only gives you the time at the start of the transaction, so you get no indication of how long anything in the transaction takes. Did you read the documentation or try it? Perhaps you're thinking of now(), current_timestamp, and friends, which don't advance during a transaction; but as the documentation states, timeofday() returns the wall-clock time and does advance during transactions. Very sorry. I did not read through the complete documentation. I just ran tests on versions of PostgreSQL going back to 7.2.8 and in all of them timeofday() advanced during a transaction. For all your work a documentation patch is appended that I think is easier to read and might avoid this problem in the future. If you don't read all the way through the current cvs version then you might think, as I did, that timeofday() is a CURRENT_TIMESTAMP related function. Sorry, but 3 lines wrap in the patch in my email client. :( Karl [EMAIL PROTECTED] Free Software: You don't pay back, you pay forward. -- Robert A. Heinlein --- func.sgml 2005-06-26 17:05:35.0 -0500 +++ func.sgml.new 2005-06-27 21:51:05.301097896 -0500 @@ -5787,15 +5787,6 @@ /para para -There is also the function functiontimeofday()/function, which for historical -reasons returns a typetext/type string rather than a typetimestamp/type value: -screen -SELECT timeofday(); -lineannotationResult: /lineannotationcomputeroutputSat Feb 17 19:07:32.000126 2001 EST/computeroutput -/screen - /para - - para It is important to know that functionCURRENT_TIMESTAMP/function and related functions return the start time of the current transaction; their values do not @@ -5803,8 +5794,7 @@ the intent is to allow a single transaction to have a consistent notion of the quotecurrent/quote time, so that multiple modifications within the same transaction bear the same -time stamp. functiontimeofday()/function -returns the wall-clock time and does advance during transactions. +time stamp. /para note @@ -5815,6 +5805,18 @@ /note para +There is also the function functiontimeofday()/function which +returns the wall-clock time and advances during transactions. For +historical reasons functiontimeofday()/function returns a +typetext/type string rather than a typetimestamp/type +value: +screen +SELECT timeofday(); +lineannotationResult: /lineannotationcomputeroutputSat Feb 17 19:07:32.000126 2001 EST/computeroutput +/screen + /para + + para All the date/time data types also accept the special literal value literalnow/literal to specify the current date and time. Thus, the following three all return the same result: ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster Karl [EMAIL PROTECTED] Free Software: You don't pay back, you pay forward. -- Robert A. Heinlein ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] [HACKERS] Proposed TODO: --encoding option for pg_dump
There's no time to do this for 8.1, but I'd like to get it on the books for 8.2: The Problem: Occassionally a DBA needs to dump a database to a new encoding. In instances where the current encoding, (or lack of an encoding, like SQL_ASCII) is poorly supported on the target database server, it can be useful to dump into a particular encoding. But, currently the only way to set the encoding of a pg_dump file is to change client_encoding in postgresql.conf and restart postmaster. This is more than a little awkward for production systems. The TODO: add an --encoding=[encoding name] option to pg_dump. This would set client_encoding for pg_dump's session(s). I *think* that's easy enough to do in time for 8.1. Trivial patch attached. I hope it's enough :-) It passed my very quick testing... (Yup, I read the mails aobut PGCLIENTENCODING, but an option to pg_dump is certainly easier) //Magnus pg_dump.diff Description: pg_dump.diff pg_dump.sgml.diff Description: pg_dump.sgml.diff ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [HACKERS] Proposed TODO: --encoding option for pg_dump
On Tue, Jun 28, 2005 at 10:24:19PM +0200, Magnus Hagander wrote: I *think* that's easy enough to do in time for 8.1. Trivial patch attached. I hope it's enough :-) It passed my very quick testing... (Yup, I read the mails aobut PGCLIENTENCODING, but an option to pg_dump is certainly easier) You forgot to document the long option, I think. -- Alvaro Herrera (alvherre[a]surnet.cl) No necesitamos banderas No reconocemos fronteras (Jorge González) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] Proposed TODO: --encoding option for pg_dump
I *think* that's easy enough to do in time for 8.1. Trivial patch attached. I hope it's enough :-) It passed my very quick testing... (Yup, I read the mails aobut PGCLIENTENCODING, but an option to pg_dump is certainly easier) You forgot to document the long option, I think. Oops. Fixed. Thanks. //Magnus pg_dump.sgml.diff Description: pg_dump.sgml.diff ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] [HACKERS] Proposed TODO: --encoding option for pg_dump
I *think* that's easy enough to do in time for 8.1. Trivial patch attached. I hope it's enough :-) It passed my very quick testing... (Yup, I read the mails aobut PGCLIENTENCODING, but an option to pg_dump is certainly easier) You forgot to document the long option, I think. Are the man pages generated from the sgml docs? Have never had a look at that. Yes - using docbook2man. //Magnus ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] [HACKERS] Proposed TODO: --encoding option for pg_dump
Alvaro Herrera wrote: On Tue, Jun 28, 2005 at 10:24:19PM +0200, Magnus Hagander wrote: I *think* that's easy enough to do in time for 8.1. Trivial patch attached. I hope it's enough :-) It passed my very quick testing... (Yup, I read the mails aobut PGCLIENTENCODING, but an option to pg_dump is certainly easier) You forgot to document the long option, I think. Are the man pages generated from the sgml docs? Have never had a look at that. Best Regards, Michael Paesold ---(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] [PATCH] pgcrypto: pgp_encrypt (v2)
On Mon, Jun 27, 2005 at 09:08:05PM -0400, Bruce Momjian wrote: Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. Please use following updated patch instead. It implements utf8 conversion, fixes couple of bugs and has many code and comment cleanups. -- marko pgp-v2.diff.gz Description: Binary data ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] COPY FROM performance improvements
Luke Lonergan wrote:
Patch to update pgindent with new symbols and fix a bug in an awk section
(extra \\ in front of a ')').
Yea, that '\' wasn't needed. I applied the following patch to use //
instead of for patterns, and removed the unneeded backslash.
I will update the typedefs in a separate commit.
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Index: src/tools/pgindent/pgindent
===
RCS file: /cvsroot/pgsql/src/tools/pgindent/pgindent,v
retrieving revision 1.73
diff -c -c -r1.73 pgindent
*** src/tools/pgindent/pgindent 7 Oct 2004 14:15:50 - 1.73
--- src/tools/pgindent/pgindent 28 Jun 2005 23:12:07 -
***
*** 50,62
if (NR = 2)
print line1;
if (NR = 2
! line2 ~ ^{[]*$
! line1 !~ ^struct
! line1 !~ ^enum
! line1 !~ ^typedef
! line1 !~ ^extern[ ][ ]*\C\
! line1 !~ =
! line1 ~ \))
print int pgindent_func_no_var_fix;;
line1 = line2;
}
--- 50,62
if (NR = 2)
print line1;
if (NR = 2
! line2 ~ /^{[]*$/
! line1 !~ /^struct/
! line1 !~ /^enum/
! line1 !~ /^typedef/
! line1 !~ /^extern[ ][ ]*C/
! line1 !~ /=/
! line1 ~ /)/)
print int pgindent_func_no_var_fix;;
line1 = line2;
}
***
*** 70,77
line2 = $0;
if (skips 0)
skips--;
! if (line1 ~ ^#ifdef[ ]*__cplusplus
! line2 ~ ^extern[ ]*\C\[]*$)
{
print line1;
print line2;
--- 70,77
line2 = $0;
if (skips 0)
skips--;
! if (line1 ~ /^#ifdef[ ]*__cplusplus/
! line2 ~ /^extern[ ]*C[ ]*$/)
{
print line1;
print line2;
***
*** 81,88
line2 = ;
skips = 2;
}
! else if (line1 ~ ^#ifdef[ ]*__cplusplus
! line2 ~ ^}[]*$)
{
print line1;
print /* Close extern \C\ */;
--- 81,88
line2 = ;
skips = 2;
}
! else if (line1 ~ /^#ifdef[ ]*__cplusplus/
! line2 ~ /^}[]*$/)
{
print line1;
print /* Close extern \C\ */;
***
*** 1732,1738
# work around misindenting of function with no variables defined
awk '
{
! if ($0 ~ ^[]*int[ ]*pgindent_func_no_var_fix;)
{
if (getline $0 != )
print $0;
--- 1732,1738
# work around misindenting of function with no variables defined
awk '
{
! if ($0 ~ /^[]*int[ ]*pgindent_func_no_var_fix;/)
{
if (getline $0 != )
print $0;
***
*** 1751,1759
# line3 = $0;
# if (skips 0)
# skips--;
! # if (line1 ~*{$
! # line2 ~*[^;{}]*;$
! # line3 ~*}$)
# {
# print line2;
# line2 = ;
--- 1751,1759
# line3 = $0;
# if (skips 0)
# skips--;
! # if (line1 ~ / *{$/
! # line2 ~ / *[^;{}]*;$/
! # line3 ~ / *}$/)
#
Re: [PATCHES] [HACKERS] Problem with dblink regression test - FIXED
On Tue, Jun 28, 2005 at 02:28:11PM -0400, Andrew Dunstan wrote: Jim C. Nasby wrote: All the logs for the most recent run against HEAD are now at http://stats.distributed.net/~buildfarm/ A quick look shows that when you use --with-libraries=/foo/bar the generated link line for libraries says -L/foo/bar -lpq and it should probably be the other way around (as it is for the executables). So I suspect we need some makefile tuning. You were correct. This patch fixes it: Index: Makefile.shlib === RCS file: /projects/cvsroot/pgsql/src/Makefile.shlib,v retrieving revision 1.90 diff -c -r1.90 Makefile.shlib *** Makefile.shlib 20 Nov 2004 21:13:04 - 1.90 --- Makefile.shlib 29 Jun 2005 00:21:10 - *** *** 240,246 SHLIB_LINK += -ltermcap -lstdc++.r4 -lbind -lsocket -L/boot/develop/lib/x86 endif ! SHLIB_LINK := $(filter -L%, $(LDFLAGS)) $(SHLIB_LINK) ifeq ($(enable_rpath), yes) SHLIB_LINK += $(rpath) endif --- 240,246 SHLIB_LINK += -ltermcap -lstdc++.r4 -lbind -lsocket -L/boot/develop/lib/x86 endif ! SHLIB_LINK := $(SHLIB_LINK) $(filter -L%, $(LDFLAGS)) ifeq ($(enable_rpath), yes) SHLIB_LINK += $(rpath) endif -- Jim C. Nasby, Database Consultant [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming, or what? ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Dbsize backend integration
Dave Page wrote: The attached patch integrates dbsize functions into the backend, as per discussion on -hackers. The following functions are included: pg_relation_size(text) - Get relation size by name/schema.name pg_relation_size(oid)- Get relation size by OID pg_tablespace_size(name) - Get tablespace size by name pg_tablespace_size(oid) - Get tablespace size by OID pg_database_size(name) - Get database size by name pg_database_size(oid)- Get database size by OID pg_table_size(text)- Get table size (including all indexes and toast tables) by name/schema.name pg_table_size(oid) - Get table size (including all indexes and toast tables) by OID pg_size_pretty(int8) - Pretty print (and round) the byte size specified (eg, 123456 = 121KB) This is based on the dbsize contrib module, and previous patches from Andreas Pflug and Ed L. The dbsize module should be removed once this is applied, and the catalog version incremented as I haven't included that in the patch. OK, so you went with relation as heap/index/toast only, and table as the total of them. I am not sure that makes sense because we usually equate relation with table, and an index isn't a relation, really. Do we have to use pg_object_size? Is there a better name? Are indexes/toasts even objects? Of course, these issues are all minor, but we might as well get them resolved. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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] slight changes to gist.sgml
Patch applied. Thanks. --- Victor Y. Yegorov wrote: Improved words spacing. -- Victor Y. Yegorov [ Attachment, skipping... ] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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 8: explain analyze is your friend
Re: [PATCHES] Fwd: Re: [PERFORM] Performance analysis of plpgsql code
Patch applied. Thanks. Your documentation changes can be viewed in five minutes using links on the developer's page, http://www.postgresql.org/developer/testing. --- Karl O. Pinc wrote: On 06/27/2005 10:03:06 PM, Karl O. Pinc wrote: On 06/27/2005 08:34:19 PM, Michael Fuhr wrote: On Tue, Jun 28, 2005 at 01:54:08AM +, Karl O. Pinc wrote: On 06/27/2005 06:33:03 PM, Michael Fuhr wrote: See timeofday(). That only gives you the time at the start of the transaction, so you get no indication of how long anything in the transaction takes. Did you read the documentation or try it? Perhaps you're thinking of now(), current_timestamp, and friends, which don't advance during a transaction; but as the documentation states, timeofday() returns the wall-clock time and does advance during transactions. Very sorry. I did not read through the complete documentation. I just ran tests on versions of PostgreSQL going back to 7.2.8 and in all of them timeofday() advanced during a transaction. For all your work a documentation patch is appended that I think is easier to read and might avoid this problem in the future. If you don't read all the way through the current cvs version then you might think, as I did, that timeofday() is a CURRENT_TIMESTAMP related function. Sorry, but 3 lines wrap in the patch in my email client. :( Karl [EMAIL PROTECTED] Free Software: You don't pay back, you pay forward. -- Robert A. Heinlein --- func.sgml 2005-06-26 17:05:35.0 -0500 +++ func.sgml.new 2005-06-27 21:51:05.301097896 -0500 @@ -5787,15 +5787,6 @@ /para para -There is also the function functiontimeofday()/function, which for historical -reasons returns a typetext/type string rather than a typetimestamp/type value: -screen -SELECT timeofday(); -lineannotationResult: /lineannotationcomputeroutputSat Feb 17 19:07:32.000126 2001 EST/computeroutput -/screen - /para - - para It is important to know that functionCURRENT_TIMESTAMP/function and related functions return the start time of the current transaction; their values do not @@ -5803,8 +5794,7 @@ the intent is to allow a single transaction to have a consistent notion of the quotecurrent/quote time, so that multiple modifications within the same transaction bear the same -time stamp. functiontimeofday()/function -returns the wall-clock time and does advance during transactions. +time stamp. /para note @@ -5815,6 +5805,18 @@ /note para +There is also the function functiontimeofday()/function which +returns the wall-clock time and advances during transactions. For +historical reasons functiontimeofday()/function returns a +typetext/type string rather than a typetimestamp/type +value: +screen +SELECT timeofday(); +lineannotationResult: /lineannotationcomputeroutputSat Feb 17 19:07:32.000126 2001 EST/computeroutput +/screen + /para + + para All the date/time data types also accept the special literal value literalnow/literal to specify the current date and time. Thus, the following three all return the same result: ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster Karl [EMAIL PROTECTED] Free Software: You don't pay back, you pay forward. -- Robert A. Heinlein ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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])
