Re: [PATCHES] pg_dump additional options for performance
Simon Riggs wrote: On Sat, 2008-07-26 at 11:03 -0700, Joshua D. Drake wrote: 2. We have no concurrency which means, anyone with any database over 50G has unacceptable restore times. Agreed. Sounds good. Doesn't help with the main element of dump time: one table at a time to one output file. We need a way to dump multiple tables concurrently, ending in multiple files/filesystems. Agreed but that is a problem I understand with a solution I don't. I am all eyes on a way to fix that. One thought I had and please, be gentle in response was some sort of async transaction capability. I know that libpq has the ability to send async queries. Is it possible to do this: send async(copy table to foo) send async(copy table to bar) send async(copy table to baz) Where all three copies are happening in the background? Sincerely, Joshua D. Drake -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] pg_dump additional options for performance
Andrew Dunstan wrote: Joshua D. Drake wrote: Agreed but that is a problem I understand with a solution I don't. I am all eyes on a way to fix that. One thought I had and please, be gentle in response was some sort of async transaction capability. I know that libpq has the ability to send async queries. Is it possible to do this: send async(copy table to foo) send async(copy table to bar) send async(copy table to baz) Where all three copies are happening in the background? IIRC, libpq doesn't let you have more than one async query active at one time. Now that I think on it harder, this isn't even a libpq problem (although its involved), we need the postmaster do be able to do a background async query. Which is (I am guessing) why libpq can only do one at a time. Sincerely, Joshua D. Drake -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] pg_dump additional options for performance
Stephen Frost wrote: * Tom Lane ([EMAIL PROTECTED]) wrote: Stephen Frost [EMAIL PROTECTED] writes: I dislike, and doubt that I'd use, this approach. At the end of the day, it ends up processing the same (very large amount of data) multiple times. This would depend on the dump being in the custom format, though I suppose that ends up being true for any usage of these options. I've never really been a fan of the custom format, in large part because it doesn't really buy you all that much and makes changing things more difficult (by having to extract out what you want to change, and then omit it from the restore). Custom format rocks for partial set restores from a whole dump. See the TOC option :) Joshua D. Drake -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] [HACKERS] Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout
Alex Hunsaker wrote: On Mon, Jun 23, 2008 at 4:51 PM, Bruce Momjian [EMAIL PROTECTED] wrote: I would like to get do this without adding a new --use-statement-timeout flag. Is anyone going to want to honor statement_timeout during pg_dump/pg_restore? I thought we were just going to disable it. I believe so. This was when not everyone was convinced. Im fairly certain Josh original patch is in the commit fest. So feel free to drop this one. My patch has been committed. Joshua D. Drake -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] SQL: table function support
On Thu, 2008-06-12 at 12:05 -0700, David Fetter wrote: On Thu, Jun 12, 2008 at 12:33:57PM -0400, Tom Lane wrote: David Fetter [EMAIL PROTECTED] writes: On Mon, Jun 09, 2008 at 05:56:59PM -0700, Neil Conway wrote: I went and got reports from the field. Over the years, I've had to explain at great length and with no certain success to developers at a dozen different companies how to use OUT parameters. RETURNS TABLE(...) is *much* more intuitive to those people, who have a tendency to do things like create temp tables rather than figure out the OUT parameter syntax afresh. Regardless of whether anyone thinks they are byzantine (or not) if RETURNS TABLE() is in the standard. We should try and implement it if we can. Sincerely, Joshua D. Drake -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [HACKERS] [PATCHES] WITH RECURSIVE patch V0.1
Hans-Juergen Schoenig wrote: Gregory Stark wrote: Joshua D. Drake [EMAIL PROTECTED] writes: i don't think statement_timeout is a good idea at all. it is not deterministic. depending on the load on the server some queries will execute while others fail. a separate GUC is needed. I don't think we need to add clutter to GUC for something that exists to handle the problem at hand. If our real concern is server utilization based on user or query resources we need to look at an overall solution for that issue not a one off for a single feature. Sincerely, Joshua D. Drake -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [HACKERS] [PATCHES] WITH RECURSIVE patch V0.1
Couldn't we just have it pay attention to the existing max_stack_depth? Recursive query does not consume stack. The server enters an infinite loop without consuming stack. Stack-depth error does not happen. We could have a separate guc variable which limits the maximum number of levels of recursive iterations. That might be a useful feature for DBAs that want to limit their users from issuing an infinite query. statement_timeout :) Joshua D. Drake -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] pg_dump lock timeout - resend
daveg wrote: On Sat, May 17, 2008 at 06:55:27PM -0300, Euler Taveira de Oliveira wrote: daveg wrote: I originally sent this a week ago, but there was no response and I do not see it Nope. FYI, the right link is [1] and your patch [2] is in the queue for July Commit Fest. [1] http://wiki.postgresql.org/wiki/Development_information [2] http://wiki.postgresql.org/wiki/CommitFest:July Thanks for the pointers. I tried finding this from the main postgresql.org developer section, so perhaps I am obtuse, or perhaps the commitfest info is not that easy to find. The pages could certainly stand an updating to reflect how development currently commences. I will work up a patch next week. Joshua D. Drake -dg -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Patch to change psql default banner v6
Tom Lane wrote: Well, the question is still where is the optional info going to go? I think what I'd find nice looking is $ psql test psql 8.4devel [ server version warning here, if needed ] [ line with SSL info here, if needed ] Type help for help. test= I do feel that the help statement ought to be on its own line; the other way is going to look cluttered, particularly as soon as there's a version warning in there. O.k. I am not trying to start an argument here but... I already sent 6 revisions of this patch that received comments and had thorough review via Alvaro. I even took into account Tom's original comments from the previous thread. This much effort on something so simple makes it not worth the effort in the first place. Bruce with respect the only useful thing I have seen you do to the patch in all this wrangling is realign the \? General options and frankly even that is suspect in my opinion. Can we either throw it away and say, Nice try JD or just commit the thing. Joshua D. Drake regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Patch to change psql default banner v6
On Thu, 15 May 2008 11:46:41 -0400 (EDT) Bruce Momjian [EMAIL PROTECTED] wrote: Bruce with respect the only useful thing I have seen you do to the patch in all this wrangling is realign the \? General options and frankly even that is suspect in my opinion. Can we either throw it away and say, Nice try JD or just commit the thing. Your patch is getting the same review any other patch would have. If you want someone else to apply it I will stop working on it. I am not asking you to not review the patch. I am asking you to be productive in doing so. Your review of this patch is basically, Even though there were two very long threads with several (on the greater side of several) different people contributing feedback, I think I know better. That behavior is frustrating, especially when I took an extreme amount of effort to address all concerns ahead of the actual commit fest. I wanted to make sure the patch would be easy to review and easy to commit. If I thought I was going to have to have the argument all over again, I just would have left the first submission as it was and then we could have burned all the time during commit fest only. Now Alvaro, Tom and I are all having the same discussion all over again but this time with Bruce. It makes no sense. Sincerely, Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate signature.asc Description: PGP signature
Re: [PATCHES] Patch to change psql default banner v6
Andrew Dunstan wrote: And for commands that have been added later, an initial version could just say this server version does not support this command. It would be already a huge improvement. Probably the biggest change would be to support versions that did not have schemas, but I think it would be OK to punt on that. We already stopped supporting 7.2 anyway. Have at it then. Prove me wrong. IMO the problem isn't the one off support for all supported version of Pg... say 7.4 - 8.4. The problem is of on going maintenance. /me doesn't think it is worth the effort. Sincerely, Joshua D. Drake -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Patch to change psql default banner v6
Bruce Momjian wrote: Alvaro Herrera wrote: Bruce Momjian wrote: If you type 'help' it just repeats the startup banner suggestion: test= help You are using psql, the command-line interface to PostgreSQL. Type \? for help. I think we wanted to have more information in 'help', not less. Making it just repeat the startup info is not very helpful. I thought about that, but aren't we just repeating the top of \?. Is that helpful? Should we just display \?. I am a little confused here. The whole point of this patch is to remove all extraneous information from the startup banner and push it to a help screen. Thus type help for help. If you type help you get your help options. I know we decided not to do that, but I am trying to figure out what the goal if 'help' is? To display the most frequently-used help commands? Aren't they at the top of \?. The purpose of help is to provide what help options there are available to those who need them. Joshua D. Drake -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Patch to change psql default banner v6
Bruce Momjian wrote: Alvaro Herrera wrote: Bruce Momjian wrote: My question is whether we agreed that suggesting help as the best way to get help was what we agreed upon? If we did, I forgot. I thought the 'help' ideas was just for people who forgot the help commands. Please review the previous discussion: http://archives.postgresql.org/message-id/1200851790.19135.68.camel%40greg-laptop OK, I just read the thread and saw no one say we should be promoting _only_ 'help' in the startup banner. Where is that email discussion? http://archives.postgresql.org/pgsql-hackers/2008-04/msg01476.php And most specifically: http://archives.postgresql.org/pgsql-hackers/2008-04/msg01376.php Joshua D. Drake -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Patch to change psql default banner v6
Bruce Momjian wrote: test= \? General \copyright show PostgreSQL usage and distribution terms \g [FILE] or ; send query buffer to server (and results to file or |pipe) \h [NAME] help on syntax of SQL commands, * for all commands \q quit psql Query Buffer \e [FILE] edit the query buffer (or file) with external editor ... I moved '\g' up into the General section rather than make it a single-entry section. send query buffer to server means nothing to a newbie. You execute queries, you don't send buffers (from a user perspective). Sincerely, Joshua D. Drake -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Patch to change psql default banner v6
Bruce Momjian wrote: Joshua D. Drake wrote: Bruce Momjian wrote: I moved '\g' up into the General section rather than make it a single-entry section. send query buffer to server means nothing to a newbie. You execute queries, you don't send buffers (from a user perspective). Yep, good, updated: General \copyright show PostgreSQL usage and distribution terms \g [FILE] or ; execute query (and send results to file or |pipe) \h [NAME] help on syntax of SQL commands, * for all commands \q quit psql Cool. Joshua D. Drake -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] configure option for XLOG_BLCKSZ
Tom Lane wrote: Mark Wong [EMAIL PROTECTED] writes: I saw a that a patch was committed that exposed a configure switch for BLCKSZ. I was hoping that I could do that same for XLOG_BLCKSZ. Well, we certainly *could*, but what's the use-case really? The case for varying BLCKSZ is marginal already, and I've seen none at all for varying XLOG_BLCKSZ. Why do we need to make it easier than edit pg_config_manual.h? The use case I could see is for performance testing but I would concur that it doesn't take much to modify pg_config_manual.h. In thinking about it, this might actually be a foot gun. You have a new pg guy, download source and think to himself..., Hey I have a 4k block size as formatted on my hard disk. Then all of a sudden they have an incompatible PostgreSQL with everything else. Sincerely, Joshua D. Drake regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] configure option for XLOG_BLCKSZ
On Fri, 2 May 2008 09:12:32 -0700 Mark Wong [EMAIL PROTECTED] wrote: I still believe it makes sense to have them separated. I did have some data, which has since been destroyed, that suggested there were some system characterization differences for OLTP workloads with PostgreSQL. Let's hope those disks get delivered to Portland soon. :) I have those disks. Joshua D. Drake Regards, Mark -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate signature.asc Description: PGP signature
[PATCHES] Patch to change psql default banner
Hello,
As discussed:
http://archives.postgresql.org/pgsql-hackers/2008-04/msg01476.php
The patch does the following:
Adds an Execution line to the \? output.
Changes the help output in mainloop.c to be more useful.
Greatly reduces overall default banner output:
* shows client version and type help for help only
* if server doesn't match shows server version too
* if there is a major version mismatch it throws a warning
Sincerely,
Joshua D. Drake
--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
? psql-Log
? psql_patch.diff
? psql_patch_v2.diff
? psql_patch_v3.diff
? psql_patch_v5.diff
? psql_path_v4.diff
Index: help.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/psql/help.c,v
retrieving revision 1.126
diff -c -r1.126 help.c
*** help.c 4 Apr 2008 18:00:25 - 1.126
--- help.c 23 Apr 2008 21:32:20 -
***
*** 168,173
--- 168,175
* if this is the start of the string then it ought to end there to fit
* in 80 columns
*/
+ fprintf(output, _(Execution\n));
+ fprintf(output, _( \\g or ; execute query\n\n));
fprintf(output, _(General\n));
fprintf(output, _( \\c[onnect] [DBNAME|- USER|- HOST|- PORT|-]\n
connect to new database (currently \%s\)\n),
Index: mainloop.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/psql/mainloop.c,v
retrieving revision 1.90
diff -c -r1.90 mainloop.c
*** mainloop.c 5 Apr 2008 03:40:15 - 1.90
--- mainloop.c 23 Apr 2008 21:32:20 -
***
*** 177,186
(line[4] == '\0' || line[4] == ';' || isspace((unsigned char) line[4])))
{
free(line);
! puts(_(You are using psql, the command-line interface to PostgreSQL.));
! puts(_(Enter SQL commands, or type \\? for a list of backslash options.));
! puts(_(Use \\h for SQL command help.));
! puts(_(Use \\q to quit.));
fflush(stdout);
continue;
}
--- 177,189
(line[4] == '\0' || line[4] == ';' || isspace((unsigned char) line[4])))
{
free(line);
! puts(_(\n));
! puts(_(You are using psql, the command-line interface to PostgreSQL.\n));
! puts(_(\tFor SQL help type \\h or \\help .));
! puts(_(\tFor help using psql type \\? .));
! puts(_(\tTo quit psql type \\q .\n));
! puts(_(\tTo view the copyright type \\copyright .\n));
!
fflush(stdout);
continue;
}
Index: prompt.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/psql/prompt.c,v
retrieving revision 1.51
diff -c -r1.51 prompt.c
*** prompt.c 1 Jan 2008 19:45:56 - 1.51
--- prompt.c 23 Apr 2008 21:32:20 -
***
*** 158,164
/* DB server user name */
case 'n':
if (pset.db)
! strlcpy(buf, session_username(), sizeof(buf));
break;
case '0':
--- 158,164
/* DB server user name */
case 'n':
if (pset.db)
! strlcpy(buf, session_username(), sizeof(buf));
break;
case '0':
Index: startup.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/psql/startup.c,v
retrieving revision 1.146
diff -c -r1.146 startup.c
*** startup.c 1 Jan 2008 19:45:56 - 1.146
--- startup.c 23 Apr 2008 21:32:20 -
***
*** 315,340
server_version = server_ver_str;
}
! printf(_(Welcome to %s %s (server %s), the PostgreSQL interactive terminal.\n\n),
! pset.progname, PG_VERSION, server_version);
! }
! else
! printf(_(Welcome to %s %s, the PostgreSQL interactive terminal.\n\n),
! pset.progname, PG_VERSION);
!
! printf(_(Type: \\copyright for distribution terms\n
! \\h for help with SQL commands\n
! \\? for help with psql commands\n
! \\g or terminate with semicolon to execute query\n
! \\q to quit\n\n));
if (pset.sversion / 100 != client_ver / 100)
! printf(_(WARNING: You are connected to a server with major version %d.%d,\n
! but your %s client is major version %d.%d. Some backslash commands,\n
! such as \\d, might not work properly.\n\n),
! pset.sversion / 1, (pset.sversion / 100) % 100,
! pset.progname,
! client_ver / 1, (client_ver / 100) % 100);
#ifdef USE_SSL
printSSLInfo();
--- 315,333
server_version = server_ver_str;
}
! printf(_(\n\t%s %s (server %s)\n\n),
! pset.progname, PG_VERSION, server_version);
! }
! else
! printf(_(%s %s\n\n
Re: [PATCHES] Patch to change psql default banner v6
On Wed, 23 Apr 2008 14:41:20 -0700
Joshua D. Drake [EMAIL PROTECTED] wrote:
Hello,
Per final discussion here:
http://archives.postgresql.org/pgsql-hackers/2008-04/msg01607.php
Joshua D. Drake
--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
Index: help.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/psql/help.c,v
retrieving revision 1.126
diff -c -r1.126 help.c
*** help.c 4 Apr 2008 18:00:25 - 1.126
--- help.c 23 Apr 2008 22:07:24 -
***
*** 168,173
--- 168,175
* if this is the start of the string then it ought to end there to fit
* in 80 columns
*/
+ fprintf(output, _(Execution\n));
+ fprintf(output, _( \\g or ; execute query\n\n));
fprintf(output, _(General\n));
fprintf(output, _( \\c[onnect] [DBNAME|- USER|- HOST|- PORT|-]\n
connect to new database (currently \%s\)\n),
Index: mainloop.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/psql/mainloop.c,v
retrieving revision 1.90
diff -c -r1.90 mainloop.c
*** mainloop.c 5 Apr 2008 03:40:15 - 1.90
--- mainloop.c 23 Apr 2008 22:07:24 -
***
*** 177,186
(line[4] == '\0' || line[4] == ';' || isspace((unsigned char) line[4])))
{
free(line);
! puts(_(You are using psql, the command-line interface to PostgreSQL.));
! puts(_(Enter SQL commands, or type \\? for a list of backslash options.));
! puts(_(Use \\h for SQL command help.));
! puts(_(Use \\q to quit.));
fflush(stdout);
continue;
}
--- 177,189
(line[4] == '\0' || line[4] == ';' || isspace((unsigned char) line[4])))
{
free(line);
! puts(_(\n));
! puts(_(You are using psql, the command-line interface to PostgreSQL.\n));
! puts(_(\t\\h or \\help for SQL help.));
! puts(_(\t\\? for psql help.));
! puts(_(\t\\q to quit psql.\n));
! puts(_(\t\\copyright to view the copyright.\n));
!
fflush(stdout);
continue;
}
Index: startup.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/psql/startup.c,v
retrieving revision 1.146
diff -c -r1.146 startup.c
*** startup.c 1 Jan 2008 19:45:56 - 1.146
--- startup.c 23 Apr 2008 22:07:24 -
***
*** 315,340
server_version = server_ver_str;
}
! printf(_(Welcome to %s %s (server %s), the PostgreSQL interactive terminal.\n\n),
! pset.progname, PG_VERSION, server_version);
! }
! else
! printf(_(Welcome to %s %s, the PostgreSQL interactive terminal.\n\n),
! pset.progname, PG_VERSION);
!
! printf(_(Type: \\copyright for distribution terms\n
! \\h for help with SQL commands\n
! \\? for help with psql commands\n
! \\g or terminate with semicolon to execute query\n
! \\q to quit\n\n));
if (pset.sversion / 100 != client_ver / 100)
! printf(_(WARNING: You are connected to a server with major version %d.%d,\n
! but your %s client is major version %d.%d. Some backslash commands,\n
! such as \\d, might not work properly.\n\n),
! pset.sversion / 1, (pset.sversion / 100) % 100,
! pset.progname,
! client_ver / 1, (client_ver / 100) % 100);
#ifdef USE_SSL
printSSLInfo();
--- 315,334
server_version = server_ver_str;
}
! printf(_(\n\t%s %s (server %s)\n\n),
! pset.progname, PG_VERSION, server_version);
! }
! else
! printf(_(%s %s\n\n),
! pset.progname, PG_VERSION);
if (pset.sversion / 100 != client_ver / 100)
! printf(_(\tWARNING: Server version %d.%d, %s version %d.%d.\n
! \tSome psql features may not work.\n\n),
! pset.sversion / 1, (pset.sversion / 100) % 100,
! pset.progname, client_ver / 1, (client_ver / 100) % 100);
!
! printf(_(Type: help for help.\n));
#ifdef USE_SSL
printSSLInfo();
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Proposed patch - psql wraps at window width
On Fri, 18 Apr 2008 17:21:26 +0100 Gregory Stark [EMAIL PROTECTED] wrote: Bryce Nesbitt [EMAIL PROTECTED] writes: I asked the folks over at Experts Exchange to test the behavior of the ioctl I always thought that was a joke domain name, like Pen Island.com. Its not and a lot of postgresql users interact there. Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] WIP: plpgsql source code obfuscation
On Sun, 6 Apr 2008 22:14:01 -0400 (EDT) Bruce Momjian [EMAIL PROTECTED] wrote: Added to TODO: o Add ability to obfuscate function bodies http://archives.postgresql.org/pgsql-patches/2008-01/msg00125.php For the record. I think this todo is bogus. We are an Open Source database, let others worry about obfuscation. It isn't like it can't be done within the facilities that already exist. Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL SPI Liaison | SPI Director | PostgreSQL political pundit signature.asc Description: PGP signature
Re: [PATCHES] Expose checkpoint start/finish times into SQL.
On Sat, 05 Apr 2008 16:37:15 +0100 Heikki Linnakangas [EMAIL PROTECTED] wrote: May I just say that every person that is currently talking on this thread is offtopic? Move it to -hackers please. Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Expose checkpoint start/finish times into SQL.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 03 Apr 2008 23:21:49 +0100 Heikki Linnakangas [EMAIL PROTECTED] wrote: Theo Schlossnagle wrote: First whack at exposing the start and finish checkpoint times into SQL. Why is that useful? For knowing how long checkpoints are taking. If they are taking too long you may need to adjust your bgwriter settings, and it is a serious drag to parse postgresql logs for this info. Joshua D. Drake - -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH9VpcATb/zqfZUUQRAiFwAJ0W7uu4Xk4DgXph1JaL180XfsAKpQCghDRw GYNE9ouPjlRhEqUmxwktDYc= =DRsZ -END PGP SIGNATURE- -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Expose checkpoint start/finish times into SQL.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 03 Apr 2008 20:29:18 -0400 Tom Lane [EMAIL PROTECTED] wrote: Joshua D. Drake [EMAIL PROTECTED] writes: Heikki Linnakangas [EMAIL PROTECTED] wrote: Why is that useful? For knowing how long checkpoints are taking. If they are taking too long you may need to adjust your bgwriter settings, and it is a serious drag to parse postgresql logs for this info. 1. To do anything useful along those lines, you would need to look at a lot of checkpoints over time, which is what log_checkpoints is good for. This patch only tells you about the latest, which isn't very useful for making any good decisions about parameters. I would agree with this. We would need a history of checkpoints that didn't reset until we told it to. 2. If I read the patch correctly, half of the time what you'd be seeing is the start time of the currently-active checkpoint and the completion time of the prior checkpoint. I don't know what those numbers are good for at all. IMO we should see start checkpoint, end checkpoint. As part of a single record. Other possibly interesting info would be how many logs were processed. 3. As of PG 8.3, the bgwriter tries very hard to make the elapsed time of a checkpoint be just about checkpoint_timeout * checkpoint_completion_target, regardless of load factors. So unless your settings are completely broken, measuring the actual time isn't going to tell you much. You assume that people don't have broken settings. :) In short: Heikki's question is on point. I didn't say it wasn't. I was just stating why a patch that does what was described is useful. I believe with changes it would still be useful. Having to go to log for a lot of this stuff is painful. Joshua D. Drake - -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH9YETATb/zqfZUUQRAmiTAJ0Shc4rSIKRG5nabAv9RwW1MVi/BQCfUIiK Nb8qyBonAlNl/Agp/wCyvTU= =H8TF -END PGP SIGNATURE- -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Expose checkpoint start/finish times into SQL.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 03 Apr 2008 20:45:37 -0400 Andrew Dunstan [EMAIL PROTECTED] wrote: Exposing everything into the log files isn't always sufficient (says the guy who maintains a remote admin tool) It should be now that you can have machine readable logs (says the guy who literally spent weeks making that happen) ;-) And how does the person get access to those? And what script do I need to write to make it happen? Don't get me wrong, the feature you worked entirely too hard on to get working is valuable but... being able to say, SELECT * FROM give_me_my_db_info; is much more useful in this context. In short, I should never have to go to log for this class of information. It should be available in the database. Sincerely, Joshua D. Drake - -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH9YF9ATb/zqfZUUQRAp+fAKCIOOKCKv5FaWiOF7hZjtLr8PzfGQCfRpq+ lY353B+9fmWwxWppAkhncMY= =BwYD -END PGP SIGNATURE- -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Expose checkpoint start/finish times into SQL.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 03 Apr 2008 21:26:46 -0400 Tom Lane [EMAIL PROTECTED] wrote: Joshua D. Drake [EMAIL PROTECTED] writes: I would agree with this. We would need a history of checkpoints that didn't reset until we told it to. Indeed, but the submitted patch has nought whatsoever to do with that. It exposes some instantaneous state. You could perhaps *build* a log facility on top of that, at the SQL level; but I don't see the point, and I definitely disagree that it would be easier than trolling the logs. Having the ability to do this: SELECT * FROM pg_stat_bgwriter WHERE last_checkpoint BETWEEN (current_time - '1 Day'::interval) AND current_time; Would be very useful. Which I can do with logs currently. You are correct. However from a usability, remote reporting and manageability perspective it certainly is not the same as something as I describe above. Note I am perfectly willing to table this until we have a full todo and specification for a feature. Sincerely, Joshua D. Drake - -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH9YVlATb/zqfZUUQRAnRxAKCab3O4dmBXctXTptDFwkRx+1zUQQCdFmsN E3GWNoC90jS7ooFgArR8Nv0= =CvMx -END PGP SIGNATURE- -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Expose checkpoint start/finish times into SQL.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 03 Apr 2008 21:44:00 -0400 Andrew Dunstan [EMAIL PROTECTED] wrote: I think there is quite possibly a good case for keeping some diagnostics in a table or tables, on a rolling basis, maybe. But then that's a facility that needs to be properly designed. Please see my later email on the thread. Joshua D. Drake - -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH9YjfATb/zqfZUUQRAnrwAKCUW76EI+lnz+qGJXFPyp9QqWJ9DgCgpnmP eiGM+P4P79O20VgBm6ew1u4= =/abt -END PGP SIGNATURE- -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Expose checkpoint start/finish times into SQL.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 03 Apr 2008 22:33:15 -0400 Tom Lane [EMAIL PROTECTED] wrote: JD seems to be on record that the existing logging mechanism sucks and he needs something else. That's fine, but I think it means that we need to improve logging in general, not invent a single-purpose mechanism for logging checkpoint times. Alright hold on. That is *not* what I said. I said *in this context* an SQL interface would be nicer. I also said that I was willing to table the entire discussion based on your review of the patch in that it didn't offer what I thought it did. Sincerely, Joshua D. Drake - -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH9ZVSATb/zqfZUUQRAhDJAJ49gMASDA40N9ydhzTTaMBdr/KccQCfei3d 4QXp/4C6iH7GXatqwU5qnuk= =slQS -END PGP SIGNATURE- -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] actualized SQL/PSM patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 01 Apr 2008 17:55:45 -0400 Tom Lane [EMAIL PROTECTED] wrote: Pavel Stehule [EMAIL PROTECTED] writes: I actualized sql/psm patch. This patch can be downloaded from http://www.pgsql.cz/patches/plpgpsm.diff.gz The fundamental problem I've got with this patch is that it adds 400K of new code (and that's just the code, not counting documentation or regression tests) that we'll have to maintain, to obtain a feature that so far as I've heard there is precisely zero demand for. That is likely because everyone knew he was working on it. Consider this my +1 for pl/psm support. The duplicativeness of the code with plpgsql doesn't make this prospect any more pleasant, either. However, I do agree with you here. I would much prefer it be cleaned up into its own space. The idea would be a lot easier to swallow if the code were refactored to avoid the duplication with plpgsql. +1. Sincerely, Joshua D. Drake - -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH9EIYATb/zqfZUUQRAmkiAJ9Q5s2Lsit7lW60sczr1/wxEGX2LACdH2rl 079G3tiL/Jj+B7FU6G5e65c= =nnba -END PGP SIGNATURE- -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] actualized SQL/PSM patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 03 Apr 2008 00:57:11 -0400 Tom Lane [EMAIL PROTECTED] wrote: Joshua D. Drake [EMAIL PROTECTED] writes: Tom Lane [EMAIL PROTECTED] wrote: The fundamental problem I've got with this patch is that it adds 400K of new code (and that's just the code, not counting documentation or regression tests) that we'll have to maintain, to obtain a feature that so far as I've heard there is precisely zero demand for. That is likely because everyone knew he was working on it. By everyone I suppose you mean the dozen or three people who are paying close attention to who's doing what in PG development. Well I think that is a bit of an understatement. I know that I have talked to people about this patch for some time. Even well before 8.3 came out. I'm not against having SQL/PSM support. I'm just saying I'm not willing to support two copies of plpgsql to do it. I didn't disagree with you Tom. Joshua D. Drake - -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH9GTnATb/zqfZUUQRAlaqAJ0bU/N625e5+BoVQRepETsU4Lij5gCfQ5qo xOqTAATx8P9AW7ZKE0qAE+I= =g2v9 -END PGP SIGNATURE- -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] script binaries renaming
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 24 Mar 2008 14:12:19 -0700 David Fetter [EMAIL PROTECTED] wrote: Yeah, I have to had two reason for this patch. First is my personal, because I don't like these names since 1999. And second is that Solaris architects do not like these names. Especially createdb and createuser. It could clash with some system utility. +1 for renaming the utilities. Not stomping on the global namespace is one place where MySQL is really out ahead of us. - -1 I have not yet seen an argument that has compelled me to actually want to have us enter the Gnome world of binary naming. However, if we *must* go down this route let us please use pgcreatedb *not* pg_createdb. Sincerely, Joshua D. Drake - -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH6BohATb/zqfZUUQRAjm5AJ0QFb1C5/BaAIMjnu/OdqTsCO/1EACfX3XL PNC+b1WIXd1fgJz23e9Gles= =UkoA -END PGP SIGNATURE- - Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] script binaries renaming
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 24 Mar 2008 18:30:46 -0400 Tom Lane [EMAIL PROTECTED] wrote: Which part of this is the wrong list wasn't clear to you guys? I actually didn't even notice. Sorry Tom. Joshua D. Drake - -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH6C1YATb/zqfZUUQRAlenAJwIBnHS0rWIyx2gE/lbeHWEmeGVgACbB/1/ HmcDiHcVbe5zhJcXW8oir1g= =KS1F -END PGP SIGNATURE- - Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Fix pgstatindex using for large indexes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 25 Feb 2008 11:21:18 -0500 Tom Lane [EMAIL PROTECTED] wrote: IIRC we are going to change datetime to integer for 8.4. We are going to change the *default* to integer. Thank goodness. Now I can stop recompiling rpms. Thanks for this - -hackers. Joshua D. Drake - -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL SPI Liaison | SPI Director | PostgreSQL political pundit -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwvkdATb/zqfZUUQRAnl8AJ4ou850ROztMxHZyGeUaD/uXQRMPACeMN9x 72FC2K3hKKV/Aq+FPWI8UJ4= =EeIA -END PGP SIGNATURE- ---(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
[PATCHES] Re: [HACKERS] Proposal for Null Bitmap Optimization(for TrailingNULLs)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 19 Dec 2007 13:46:15 -0500 Andrew Dunstan [EMAIL PROTECTED] wrote: I would suggest forgetting that part and submitting the part that has some chance of getting accepted. Actually i want to submit the patch, which is best according to me. You do need to be able to be able to feel that your work is up to a standard that you find redeemable. However... That's not an attitude that is likely to succeed - you need to take suggestions from Tom very seriously. Andrew is absolutely correct here. If you do not agree with Tom, you best prove why. Otherwise your patch will likely be ignored on submission. Sincerely, Joshua D. Drake - -- The PostgreSQL Company: Since 1997, http://www.commandprompt.com/ Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate SELECT 'Training', 'Consulting' FROM vendor WHERE name = 'CMD' -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHaWj9ATb/zqfZUUQRAqsNAJ9k6p0z7rQEcqal0JoKw/ZZG8h5kACfaB9y xQJ4O+h1xe947O1gnTLEbTU= =WaSW -END PGP SIGNATURE- ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] DDL in EDB-SPL
Pavel Stehule wrote: Wrong address :) O.k. now that makes more sense :) Joshua D. Drake Pavel On 12/12/2007, Heikki Linnakangas [EMAIL PROTECTED] wrote: While looking at the package function precedence problem, I bumped into another unrelated bug: ---(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] pgbench - startup delay
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 10 Dec 2007 19:58:21 + Dave Page [EMAIL PROTECTED] wrote: Neil Conway wrote: On Mon, 2007-12-10 at 19:27 +, Dave Page wrote: Whilst doing some profiling of the server I found it useful to add an option to pgbench to introduce a delay between client connection setup and the start of the benchmark itself to allow me time to attach the profiler to one of the backends. postgres -W n already does this. It is more flexible to put this functionality in the backend that in individual client apps anyway. I'm aware of postgres -W, but wanted something that wouldn't get in the way of other connections and would only affect my pgbench tests. If the patch is of no interest, please just ignore it. I just posted it for anyone that may find it useful - I'm not pushing to have it committed. I see use for it. Especially in a development environment where you may have various things going on that you have no control over. It is rude to send out a broadcast that says, Yo... I need to restart postgresql, please stop all productive tasks on your end because I am more important. +1 on enabling client side behavior. Joshua D. Drake - -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHXZtEATb/zqfZUUQRAiWoAJ0ULTUziKVDkuqXmUyvgYCSA0f+hwCgl/ay SZjqJZIaGLxTBpbuKEzBc4Y= =Ku+C -END PGP SIGNATURE- ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Proposed patch to disallow password=foo in database name parameter
Tom Lane wrote: As of PG 8.3, libpq allows a conninfo string to be passed in via the dbName parameter of PQsetdbLogin. This is to allow access to conninfo facilities in old programs that are still using PQsetdbLogin (including most of our own standard clients ... ahem). For instance psql service = foo Andrew Dunstan pointed out a possible security hole in this: it will allow people to do psql dbname = mydb password = mypassword which would leave their password exposed on the program's command line. While we cannot absolutely prevent client apps from doing stupid things, it seems like it might be a good idea to prevent passwords from being passed in through dbName. The attached patch (which depends on some pretty-recent changes in CVS HEAD) accomplishes this. Anybody think this is good, bad, or silly? Does the issue need I didn't even know we could do that. I always use the shell variable option instead. Does anyone actually use the facility? explicit documentation, and if so where and how? I think it should just throw a syntax error, this isn't covered as an ability in the man page. I doubt anyone is honestly using this that isn't smart enough to just figure out it isn't supported. Joshua D. Drake ---(end of broadcast)--- TIP 1: 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] Proposed patch to disallow password=foo in database name parameter
Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: Tom Lane wrote: As of PG 8.3, libpq allows a conninfo string to be passed in via the dbName parameter of PQsetdbLogin. I didn't even know we could do that. I always use the shell variable option instead. Does anyone actually use the facility? Well, not yet, because it's new in 8.3 ... Yeah, let's not do that. Like you said, While we cannot absolutely prevent client apps from doing stupid things, it seems like it might be a good idea to prevent passwords from being passed in through dbName. To me... this is something that if we allow, people will use it, and we will end up removing it, realizing it is a bad idea. There are plenty of other ways to pass the password in a more sane way. Sincerely, Joshua D. Drake regards, tom lane ---(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] [DOCS] Partition: use triggers instead of rules
Michael Paesold wrote: NikhilS wrote: noteparaIf you have a partitioning setup that uses rules please refer to the 8.2 documentation on partitioning/para/note +1 I would also add another sentence about *why* the recommendation was changed. We have one rule-based setup here, and it has been working flawlessly for us,... so personally I don't even know the reasons. Rules are extremely slow in comparisons and not anywhere near as flexible. As I said up post yesterday... they work well in the basic partitioning configuration but anything else they are extremely deficient. Joshua D. Drake Best Regards Michael Paesold ---(end of broadcast)--- TIP 1: 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 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [DOCS] Partition: use triggers instead of rules
Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: Rules are extremely slow in comparisons and not anywhere near as flexible. As I said up post yesterday... they work well in the basic partitioning configuration but anything else they are extremely deficient. I think that the above claim is exceedingly narrow-minded. We are talking about partitioning. It is supposed to be narrow-minded. A trigger will probably beat a rule for inserts/updates involving a small number of rows. Which is exactly what partitioning is doing. For large numbers of rows, like an INSERT/SELECT from another large table, the rule is likely to win, because its overhead is paid once per query not once per row. Also, if you implement the trigger with an EXECUTE (forcing a planning cycle) intead of hard-coded commands, the speed advantage becomes even more dubious. Not for partitioning. Although I agree with your sentiments for normal operation. Sincerely, Joshua D. Drake ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] [DOCS] Partition: use triggers instead of rules
Bruce Momjian wrote: Joshua D. Drake wrote: Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: Rules are extremely slow in comparisons and not anywhere near as flexible. As I said up post yesterday... they work well in the basic partitioning configuration but anything else they are extremely deficient. I think that the above claim is exceedingly narrow-minded. We are talking about partitioning. It is supposed to be narrow-minded. Sure, but look at all the confusion we have had just on this list about it. We had better state why triggers should be used in place of rules _for_ _partitioning_ or that confusion will continue. Sure I have no problem with that. Joshua D. Drake ---(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] [DOCS] Partition: use triggers instead of rules
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 29 Nov 2007 17:29:51 + Gregory Stark [EMAIL PROTECTED] wrote: Joshua D. Drake [EMAIL PROTECTED] writes: Heh, o.k. that was an ambiguous sentence. In a partitioned environment you are likely not moving millions of rows around. Thus the rule benefit is lost. You are instead performing many (sometimes lots-o-many) inserts and updates that involve a small number of rows. I'm still not following at all. If you're partitioning it's because you have a *lot* of data. It doesn't say anything about what you're If you have lots of data it doesn't mean you are modifying lots of data. I took perhaps incorrectly what tgl said as modifying lots of data. E.g; I am doing a large transaction that is going to insert/update 500 thousand rows. I don't think anyone here (good lord I hope not) would say that firing a trigger over 500k rows is fast. Instead you should likely just work the data outside the partition and then move it directly into the target partition. doing with that data. Partitioning is useful for managing large quantities of data for both OLTP and DSS systems. Certainly. I am not really arguing that and I would tend to agree that I am being very focused on my arguments about partitioning. To me it is obvious that you don't use triggers or rules when moving tons of data, either one is just a burden you don't need. Partitioning is generally most useful for: Breaking up large tables and indexes so you are dealing with less data on active queries. Breaking up large tables so you don't end up vacuuming at 500 million row table that only 1 million rows are ever updated. Rotating out highly updated data so you can keep bloat down (HOT resolves this in certain cases). General data management of large sets. Archives and the like. In any of the above cases a trigger is going to work better than a rule with the exceptions of what TGL pointed out and in simpler partitioning environments where the number of partitions are very low. Either way, to drive this back to topic :).. on the docs if we keep the rule example it should be below the partitioned example and we need to list caveats on both. Which I personally think is overkill for reference documentation but it seems to be what some people want. I tend to be happier recommending triggers over rules if only because rules are just harder to understand. Arguably they don't really work properly for this use anyways given what happens if you use volatile functions like random() in your where clause. nod. Sincerely, Joshua D. Drake - -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHTvxkATb/zqfZUUQRAhRtAKCHcWBhVZgTM8XXq8kJWWmi0m49cACgmAU5 xqosTo6sJPqpMMKWNvoTWGU= =zDUw -END PGP SIGNATURE- ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] [DOCS] Partition: use triggers instead of rules
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 28 Nov 2007 12:26:15 -0800 David Fetter [EMAIL PROTECTED] wrote: Folks, Best practices for partitioning so far have shown that TRIGGERs are better than RULEs for most cases. Please find attached a patch which reflects this. Thanks to Robert Treat for help putting this together :) Cheers, David. +1 Joshua D. Drake - -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHTdHoATb/zqfZUUQRAnpWAJ9xHqMnNorANuS9r8Hm90tn2bmZIwCglwlq D7Q1C5vcbvQ/JiqVcv0wCho= =NcWZ -END PGP SIGNATURE- ---(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] [DOCS] Partition: use triggers instead of rules
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 28 Nov 2007 12:57:10 -0800 David Fetter [EMAIL PROTECTED] wrote: On Wed, Nov 28, 2007 at 03:53:04PM -0500, Tom Lane wrote: David Fetter [EMAIL PROTECTED] writes: Best practices for partitioning so far have shown that TRIGGERs are better than RULEs for most cases. Please find attached a patch which reflects this. Entirely removing the example of how to do it with rules doesn't seem like a good idea. It does to me. I haven't found a case yet where rules worked even as well as triggers. I have yet to see a place that rules are appropriate at all with partitioning. The only half reasonable argument to their existence with it is that they are easier for someone with an extremely simple partitioning configuration. However rules are so deficient on anything except the absolute most basic example of partitioning that I think we are doing our new partitioning users a disservice by stating anything about rules except in passing. Sincerely, Joshua D. Drake Cheers, David. - -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHTdeuATb/zqfZUUQRAvf3AJ96e4YynZ/rYv6egG+w+85Ms+ihogCgjIlh 6xWR0nzceoJYCiQl+ffFTK8= =XREP -END PGP SIGNATURE- ---(end of broadcast)--- TIP 1: 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] [DOCS] Partition: use triggers instead of rules
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 29 Nov 2007 00:55:53 -0500 Tom Lane [EMAIL PROTECTED] wrote: David Fetter [EMAIL PROTECTED] writes: On Wed, Nov 28, 2007 at 09:58:26PM -0500, Jonah H. Harris wrote: On Nov 28, 2007 3:53 PM, Tom Lane [EMAIL PROTECTED] wrote: Entirely removing the example of how to do it with rules doesn't seem like a good idea. Agreed. Do you have an example of one use case where using RULEs rather than TRIGGERs is a good idea? The argument I made for keeping the example around is not dependent on the assumption that using a rule is a good idea. It's dependent on the established fact that we have recommended that in prior releases, and therefore people are going to be seeing that construct in real databases. And they could refer back to the older version of the documentation for it. In fact, we should mention that in the patch: noteparaIf you have an partitioning setup that uses rules please refer to the 8.2 documentation on partitioning/para/note Sincerely, Joshua D. Drake regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org - -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHTl84ATb/zqfZUUQRAtscAJ9h77nDNJ3ZggWgocXDQaFE/S998gCcDtiV wKH3BejsoL0fR5D3KHhKaEc= =zpPv -END PGP SIGNATURE- ---(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] fulltext parser strange behave
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 19 Nov 2007 11:49:35 -0500 Andrew Dunstan [EMAIL PROTECTED] wrote: Most people haven't heard of SGML. I'd settle for XML tag or maybe XML/HTML tag. Any other bids? XML tag is fine, imo. Sincerely, Joshua D. Drake cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings - -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHQcFEATb/zqfZUUQRAnpqAKCRPpvG/AQmI5qqkokC1u13gdGw2ACcCC8J o9F/VjTRIPrLynuJQnJB0L8= =X0Kn -END PGP SIGNATURE- ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] Unclarity of configure options
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 4 Nov 2007 13:11:00 -0500 (EST) Bruce Momjian [EMAIL PROTECTED] wrote: Nikolay Samokhvalov wrote: The current (CVS version) configure script has the following options (among many others): --enable-dtrace build with DTrace support --with-ossp-uuidbuild with OSSP UUID library for UUID generation --with-libxml build with XML support --with-libxslt build with XSLT support One could think that adding any of this option to ./configure before building Postgres from sources, he will have corresponding support after installation and initdb process. But what we have now is the huge difference between --with-libxml and --with-libxslt: while the first one adds XML support to the core, the second one doesn't provide anything automatically, it allows only using contirb/xml2 (what is unclear because the help message is the same as for --with-libxml -- build with ... support). I have modified the configure message to be: --with-libxslt build /contrib/xml2 with XSLT support Patch attached. Shouldn't --with-libxml be noted as deprecated? Joshua D. Drake - -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHLgwBATb/zqfZUUQRAsLYAJ9xIrfHnidg0BPW6durNvl61VVT8wCfdY4i kKSUyVxwaFazYlcY7SCkiCY= =A8DO -END PGP SIGNATURE- ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] [HACKERS] Unclarity of configure options
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 04 Nov 2007 13:24:54 -0500 Tom Lane [EMAIL PROTECTED] wrote: Joshua D. Drake [EMAIL PROTECTED] writes: Shouldn't --with-libxml be noted as deprecated? Huh? Because in 8.3 it is in core or am I misunderstanding the difference? Joshua D. Drake regards, tom lane ---(end of broadcast)--- TIP 1: 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 - -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHLhmXATb/zqfZUUQRAuBJAJ9jFV8DaxWzWJKhjIPTkeXZ1OWRVQCfTaiV 5ytxcL5Q+Xc3tEAxoj7bbPY= =tLkt -END PGP SIGNATURE- ---(end of broadcast)--- TIP 1: 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] [HACKERS] Unclarity of configure options
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 4 Nov 2007 14:17:48 -0500 (EST) Bruce Momjian [EMAIL PROTECTED] wrote: The functionality is in 8.3 and we areC keeping the /contrib/xml2 API around for those who need it. The release notes have: * contrib/xml2 is deprecated and planned for removal in 8.4 (Peter) The new XML support in core Postgres supersedes this module. Do we need more than that? I don't think so. Well that was exactly my point, contrib/xml2 is deprecated as of 8.3 so it may make sense to make sure the configure says exactly that. If not, it isn't that big of a deal. I was just making a suggestion to try and help stop confusion in the future. Sincerely, Joshua D. Drake - -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHLhz1ATb/zqfZUUQRAmBcAJ9ToftpalD9kH5x+Vwy+SVHn6qB8ACbBB4d D+lV9utI9iNhlK7F0qjhFMk= =uovh -END PGP SIGNATURE- ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] Unclarity of configure options
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 4 Nov 2007 14:18:23 -0500 (EST) Bruce Momjian [EMAIL PROTECTED] wrote: Stefan Kaltenbrunner wrote: Joshua D. Drake wrote: On Sun, 04 Nov 2007 13:24:54 -0500 Tom Lane [EMAIL PROTECTED] wrote: Joshua D. Drake [EMAIL PROTECTED] writes: Shouldn't --with-libxml be noted as deprecated? Huh? Because in 8.3 it is in core or am I misunderstanding the difference? you missunderstand - the XML support in 8.3 requires libxml and is only compiled in if that configure switch is selected ... Right, that too. Aha! O.k. that is what I missed. Suggestion withdrawn. Sincerely, Joshua D. Drake - -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHLh0oATb/zqfZUUQRAhVEAJ4nW8AS+gR7EOKl4UY4e7NCc/hFHACgmtpU brAYEQ+UhIMBWL9wxQFM+CA= =B7xe -END PGP SIGNATURE- ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[PATCHES] Patch to update log levels
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Here is a patch that documents the syslog log levels and their correlation to the PostgreSQL log levels per: http://archives.postgresql.org/pgsql-general/2007-09/msg00982.php Joshua D. Drake - -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG8xNiATb/zqfZUUQRAodGAKCUiMZf1TUlMF+ijFM9jmndIkxp9wCgp13L 6EyxUqI7ycMw3w8ZeOeexwQ= =0KcO -END PGP SIGNATURE- *** config.sgml 2007-09-20 17:39:44.0 -0700 --- config.sgml.jd 2007-09-20 17:39:18.0 -0700 *** *** 2625,2631 termliteralDEBUG[1-5]/literal/term listitem para ! Provides information for use by developers. /para /listitem /varlistentry --- 2625,2631 termliteralDEBUG[1-5]/literal/term listitem para ! Provides information for use by developers. The syslog facility will log DEBUG[1-5] as LOG_DEBUG. /para /listitem /varlistentry *** *** 2635,2641 listitem para Provides information implicitly requested by the user, ! e.g., during commandVACUUM VERBOSE/. /para /listitem /varlistentry --- 2635,2641 listitem para Provides information implicitly requested by the user, ! e.g., during commandVACUUM VERBOSE/. The syslog facility will log INFO as LOG_INFO. /para /listitem /varlistentry *** *** 2646,2652 para Provides information that might be helpful to users, e.g., truncation of long identifiers and the creation of indexes as part ! of primary keys. /para /listitem /varlistentry --- 2646,2652 para Provides information that might be helpful to users, e.g., truncation of long identifiers and the creation of indexes as part ! of primary keys. The syslog facility will log NOTICE as LOG_NOTICE. /para /listitem /varlistentry *** *** 2656,2662 listitem para Provides warnings to the user, e.g., commandCOMMIT/ ! outside a transaction block. /para /listitem /varlistentry --- 2656,2662 listitem para Provides warnings to the user, e.g., commandCOMMIT/ ! outside a transaction block. The syslog facility will log WARNING as LOG_NOTICE. /para /listitem /varlistentry *** *** 2665,2671 termliteralERROR/literal/term listitem para ! Reports an error that caused the current command to abort. /para /listitem /varlistentry --- 2665,2671 termliteralERROR/literal/term listitem para ! Reports an error that caused the current command to abort. The syslog facility will log ERROR as LOG_WARNING. /para /listitem /varlistentry *** *** 2675,2681 listitem para Reports information of interest to administrators, e.g., ! checkpoint activity. /para /listitem /varlistentry --- 2675,2681 listitem para Reports information of interest to administrators, e.g., ! checkpoint activity. The syslog facility will log LOG as LOG_INFO. /para /listitem /varlistentry *** *** 2684,2690 termliteralFATAL/literal/term listitem para ! Reports an error that caused the current session to abort. /para /listitem /varlistentry --- 2684,2690 termliteralFATAL/literal/term listitem para ! Reports an error that caused the current session to abort. The syslog facility will log FATAL as LOG_ERR. /para /listitem /varlistentry *** *** 2693,2699 termliteralPANIC/literal/term listitem para ! Reports an error
Re: [PATCHES] [DOCS] Patch to update log levels
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: Here is a patch that documents the syslog log levels and their correlation to the PostgreSQL log levels per: This seems like quite the wrong place to document it --- I'd have thought somewhere near the discussion of syslog logging would be appropriate. Putting it here means you're in the face of people who do not even have syslog (ie, Windows users) Fair enough. Except that we don't really talk about syslog anywhere. We do here: http://developer.postgresql.org/pgdocs/postgres/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-WHERE Which is pretty much where I put it. Do we have some kind of correlation for eventlog on windows? Then I could just use a table to show the relationships. Something like: Log Level PostgreSQL Syslog EventLog Panic LOG_CRITUsual Behavior Sincerely, Joshua D. Drake regards, tom lane - -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG8xnvATb/zqfZUUQRAjVLAKCaSj8FRfz4XXQmHsdzFKxEE49lNQCgiH0z yVIbB+YCyiP1HXLWrvujg38= =GtSc -END PGP SIGNATURE- ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] [DOCS] Patch to update log levels
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Joshua D. Drake wrote:
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Here is a patch that documents the syslog log levels and their
correlation to the PostgreSQL log levels per:
This seems like quite the wrong place to document it --- I'd have
thought somewhere near the discussion of syslog logging would be
appropriate. Putting it here means you're in the face of people
who do not even have syslog (ie, Windows users)
Fair enough. Except that we don't really talk about syslog anywhere. We
do here:
http://developer.postgresql.org/pgdocs/postgres/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-WHERE
Which is pretty much where I put it.
Do we have some kind of correlation for eventlog on windows? Then I
could just use a table to show the relationships. Something like:
Is this correct for Windows?
1392switch (level)
1393{
1394case DEBUG5:
1395case DEBUG4:
1396case DEBUG3:
1397case DEBUG2:
1398case DEBUG1:
1399case LOG:
1400case COMMERROR:
1401case INFO:
1402case NOTICE:
1403eventlevel = EVENTLOG_INFORMATION_TYPE;
1404break;
1405case WARNING:
1406eventlevel = EVENTLOG_WARNING_TYPE;
1407break;
1408case ERROR:
1409case FATAL:
1410case PANIC:
1411default:
1412eventlevel = EVENTLOG_ERROR_TYPE;
1413break;
1414}
Sincerely,
Joshua D. Drake
Log Level
PostgreSQLSyslog EventLog
Panic LOG_CRITUsual Behavior
Sincerely,
Joshua D. Drake
regards, tom lane
- ---(end of broadcast)---
TIP 6: explain analyze is your friend
- --
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240
PostgreSQL solutions since 1997 http://www.commandprompt.com/
UNIQUE NOT NULL
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFG8x4cATb/zqfZUUQRAmaPAKCQIpHDRBCFP9pLlyi88huJKyWbFgCfd4K3
EGs9/5lJEkV1UxJuqJBUXFY=
=f9R/
-END PGP SIGNATURE-
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
Re: [PATCHES] script binaries renaming
Michael Glaesemann wrote: On Jul 6, 2007, at 5:53 , Dave Page wrote: On Fri, July 6, 2007 8:51 am, Peter Eisentraut wrote: Am Mittwoch, 4. Juli 2007 17:04 schrieb Zdenek Kotala: I attach complete patch which renames following binaries createdb createlang createuser dropdb droplang dropuser clusterdb vacuumdb reindexdb I just want to say I dislike this idea. This is almost as bad as Magnus agreeing with JD (!), but I agree with Peter :-). After years of typing the current names, changing them does seem somewhat annoying. Worse yet, pg_* is just awkward to type. While the change might be awkward, the names of these binaries really should be namespaced in some way. The current just too generic to be throwing into a bin/ directory in my opinion. Of course I realize that I voted for the idea in the first place. I voted for it for consistency more than anything but as I think about it, it really is clunky and doesn't serve any real purpose. Joshua D. Drake Michael Glaesemann grzm seespotcode net ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] script binaries renaming
Michael Glaesemann wrote: On Jul 6, 2007, at 5:53 , Dave Page wrote: On Fri, July 6, 2007 8:51 am, Peter Eisentraut wrote: Am Mittwoch, 4. Juli 2007 17:04 schrieb Zdenek Kotala: I attach complete patch which renames following binaries createdb createlang createuser dropdb droplang dropuser clusterdb vacuumdb reindexdb I just want to say I dislike this idea. This is almost as bad as Magnus agreeing with JD (!), but I agree with Peter :-). After years of typing the current names, changing them does seem somewhat annoying. Worse yet, pg_* is just awkward to type. While the change might be awkward, the names of these binaries really should be namespaced in some way. The current just too generic to be throwing into a bin/ directory in my opinion. Why should they be name spaced? I see zero reason why that should be the case... apache_httpd? gnu_ls? The only obvious name spaced applications out there are in the G/K world of nome and de. Joshua D. Drake Michael Glaesemann grzm seespotcode net ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] psql: add volatility to \df+
Tom Lane wrote: Neil Conway [EMAIL PROTECTED] writes: Attached is a patch that adds information about function volatility to the output of psql's \df+ slash command. I'll apply this to HEAD tomorrow, barring any objections. +1, but are there not any documentation changes to make? Well here is a question (just because I haven't seen it) is there a list of functions and their volatility in the docs? Joshua D. Drake regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Standard compliant DEFAULT clause
Zoltan Boszormenyi wrote:
Hi,
here's a fix for a _very_ longstanding bug in PostgreSQL.
According to SQL:2003 DEFAULT may only contain
certain functional expressions and constant literals.
Please, note the year of the standard. Or I know a better one,
PostgreSQL is not even SQL92 compliant in this regard, after 14 years!
http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt
Please review and apply immediately.
Or not, it's just a bitter and late (because of my bitterness) response
to the rejection of my IDENTITY/GENERATED patches.
Where's the much praised standard behaviour on standard syntax?
So much for hypocrisy.
Antagonism will not help your cause.
Joshua D. Drake
--- pgsql.orig/src/backend/catalog/heap.c 2007-05-15 09:34:25.0
+0200
+++ pgsql/src/backend/catalog/heap.c2007-05-18 21:33:04.0 +0200
@@ -1935,6 +1935,43 @@
errmsg(cannot use column references in default
expression)));
/*
+* Make sure default expr may contain only
+* standard compliant functions as of SQL:2003:
+* - CURRENT_DATE
+* - CURRENT_TIME[ ( precision ) ]
+* - CURRENT_TIMESTAMP[ ( precision ) ]
+* - LOCALTIME[ ( precision ) ]
+* - LOCALTIMESTAMP[ ( precision ) ]
+* - as a PostgreSQL extension,
+* all others that call now() implicitely or explicitely
+* - USER
+* - CURRENT_USER
+* - CURRENT_ROLE
+* - SESSION_USER
+* with two other PostgreSQL extensions:
+* - nextval() so SERIALs work
+* - any immutable functions to pave the way for GENERATED columns
+* Please note that PostgreSQL lacks SYSTEM_USER and CURRENT_PATH.
+*/
+ if (is_opclause(expr)) {
+ OpExpr *clause = (OpExpr *)expr;
+
+ switch (clause-opfuncid)
+ {
+ case 745: /* current_user */
+ case 746: /* session_user */
+ case 1299: /* now() */
+ case 1574: /* nextval() */
+ break;
+ default:
+ if (contain_mutable_functions(expr))
+ ereport(ERROR,
+
(errcode(ERRCODE_INVALID_OBJECT_DEFINITION),
+ errmsg(cannot use non-IMMUTABLE
functions in default expression)));
+ }
+ }
+
+ /*
* It can't return a set either.
*/
if (expression_returns_set(expr))
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
---(end of broadcast)---
TIP 1: 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] [HACKERS] Full page writes improvement, code update
In terms of idle time for gzip and other command to archive WAL offline, no difference in the environment was given other than the command to archive. My guess is because the user time is very large in gzip, it has more chance for scheduler to give resource to other processes. In the case of cp, idle time is more than 30times longer than user time. Pg_compresslog uses seven times longer idle time than user time. On the other hand, gzip uses less idle time than user time. Considering the total amount of user time, I think it's reasonable measure. Again, in my proposal, it is not the issue to increase run time performance. Issue is to decrease the size of archive log to save the storage. Considering the relatively little amount of storage a transaction log takes, it would seem to me that the performance angle is more appropriate. Is it more efficient in other ways besides negligible tps? Possibly more efficient memory usage? Better restore times for a crashed system? Sincerely, Joshua D. Drake Regards; -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(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] autovacuum multiworkers, patch 5
Alvaro Herrera wrote: Hi, uhmmm patch? Here is the autovacuum patch I am currently working with. This is basically the same as the previous patch; I have tweaked the database list management so that after a change in databases (say a new database is created or a database is dropped), the list is recomputed to account for the change, keeping the ordering of the previous list. Modulo two low probability failure scenarios, I feel this patch is ready to be applied; I will do so on Friday unless there are objections. The failure scenarios are detailed in the comment pasted below. I intend to attack these problems next, but as the first one should be fairly low probability, I don't think it should bar the current patch from being applied. (The second problem, which seems to me to be the most serious, should be easily fixable by checking launch times and -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] autovacuum multiworkers, patch 5
Alvaro Herrera wrote: ITAGAKI Takahiro wrote: Alvaro Herrera [EMAIL PROTECTED] wrote: Here is the autovacuum patch I am currently working with. This is basically the same as the previous patch; I have tweaked the database list management so that after a change in databases (say a new database is created or a database is dropped), the list is recomputed to account for the change, keeping the ordering of the previous list. I'm interested in your multiworkers autovacuum proposal. I'm researching the impact of multiworkers with autovacuum_vacuum_cost_limit. Autovacuum will consume server resources up to autovacuum_max_workers times as many as before. I think we might need to change the semantics of autovacuum_vacuum_cost_limit when we have multiworkers. Yes, that's correct. Per previous discussion, what I actually wanted to do was to create a GUC setting to simplify the whole thing, something like autovacuum_max_mb_per_second or autovacuum_max_io_per_second. Then, have each worker use up to (max_per_second/active workers) as much IO resources. This way, the maximum use of IO resources by vacuum can be easily determined and limited by the DBA; certainly much simpler than the vacuum cost limiting feature. +1 Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(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: [HACKERS] [PATCHES] xml2 contrib patch supporting default XML namespaces
Peter Eisentraut wrote: Mike Rylander wrote: A related question, however: Will the XML features being included in 8.3 support namespace prefix registration? That is certainly the plan. Let me bounce my ostrich (sp?) head up here and say, thanks for your work on this Peter. Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] POSIX shared memory support
If you have the need to ship a product with Postgres embedded in it and are unable to change kernel settings (like myself), this might be of use to you. I have tested all of the failure situations I could think of by various combinations of deleting lockfiles while in use, changing the PID inside the lockfile and trying to restart and run more than one postmaster simultaneously. Of course, this since this requires both POSIX and SysV shared memory, this doesn't increase the portability of Postgres which might make it less appropriate for mass distribution; I thought I would put it out there for any feedback either way. Well that depends, what systems don't use (or have) POSIX shared memory? This sounds very interesting to me. Oddly enough I went to do some digging on what various differences and I came up with: http://www.nabble.com/POSIX-shared-memory-support-t3298386.html Which happens to be you ;) Sincerely, Joshua D. Drake Thanks again, Chris Marcellino ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [PATCHES]
Bruce Momjian wrote: I have added this to the developer's FAQ to clarify the situtation of posting a patch: liPostgreSQL is licensed under a BSD license. By posting a patch to the public PostgreSQL mailling lists, you are giving the PostgreSQL Global Development Group the non-revokable right to distribute your patch under the BSD license. If you use code that is available under some other license that is BSD compatible (eg. public domain), please note that in your email submission./li We should add this to the mailing list signup pages and the welcome pages to the lists. Joshua D. Drake --- Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Neil Conway wrote: For the case in question, sure, requiring some clarification from FJ would be reasonable. But more broadly, my point is that I think you're fooling yourself if you think that requiring a disclaimer or explicit transfer of copyright for this *one* particular patch is likely to make any material difference to the overall copyright status of the code base. Yes, I do. If there is an explicit claim, like an email footer or a copyright in the code, we do try to nail that down. AFAICT, the footer in question tries to make it illegal for us even to have the message in our mail archives. If I were running the PG lists, I would install filters that automatically reject mails containing such notices, with a message like Your corporate lawyers do not deserve to have access to the internet. Go away until you've acquired a clue. I fully support Bruce's demand that patches be submitted with no such idiocy attached. regards, tom lane -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [PATCHES]
FAST PostgreSQL wrote: On Thu, 1 Mar 2007 04:28, Bruce Momjian wrote: I have added this to the developer's FAQ to clarify the situtation of posting a patch: liPostgreSQL is licensed under a BSD license. By posting a patch to the public PostgreSQL mailling lists, you are giving the PostgreSQL Global Development Group the non-revokable right to distribute your patch under the BSD license. If you use code that is available under some other license that is BSD compatible (eg. public domain), please note that in your email submission./li We are happy to do this for every patch we submit. We can add an explicit statement which will put our contribution under the BSD license. This statement will override the email signature and will be approved by the appropriate person. Rgds, Arul Shaji I know that I can speak for the community when I say, Thanks to you and Fujitsu for taking our concerns into consideration. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(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: [HACKERS] [PATCHES]
Bruce Momjian wrote: FYI, I am not going to be comfortable accepting a final patch that contains this email signature: This is an email from Fujitsu Australia Software Technology Pty Ltd, ABN 27 003 693 481. It is confidential to the ordinary user of the email address to which it was addressed and may contain copyright and/or - legally privileged information. No one else may read, print, store, copy or forward all or any of it or its attachments. If you receive this email in error, please return to s ender. Thank you. unless you provide additional details on your contribution of this code under a BSD license. Gonna have to concur with that. Not that the sig is legally binding anyway, we do need to have a disclaimer in the email stating that you are assigning to PGDG Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [PATCHES]
Neil Conway wrote: On Tue, 2007-02-27 at 14:52 -0800, Joshua D. Drake wrote: Gonna have to concur with that. Not that the sig is legally binding anyway, we do need to have a disclaimer in the email stating that you are assigning to PGDG I think it's pretty silly to start caring about this now. Do you think that in the absence of any signature/disclaimer attached to a patch, then the copyright for the change is implicitly assigned to PGDG? (I'm not a lawyer, but I believe that's not the case.) I can tell you that it depends on the individuals relationship with their employer. The employer may have agreement (most do) that will state that whatever the employee does is owned by the employer. Thus we may literally not have rights to the code. Do you really want to go down the path of in 2 years, Fujitsu (No offense Fujitsu), but you are the topic) decides that the code they provided is owned by them and they didn't give us permission? Joshua D. Drake -Neil -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(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: [HACKERS] [PATCHES]
Yes, I do. If there is an explicit claim, like an email footer or a copyright in the code, we do try to nail that down. AFAICT, the footer in question tries to make it illegal for us even to have the message in our mail archives. If I were running the PG lists, I would install filters that automatically reject mails containing such notices, with a message like Your corporate lawyers do not deserve to have access to the internet. Go away until you've acquired a clue. Well that would pretty much eliminate the ability to receive mail from any large company :) but I can certainly appreciate the sentiment. I fully support Bruce's demand that patches be submitted with no such idiocy attached. Absolutely. In regards to your idea of a filter, there is no reason why we couldn't install a filter that checks for signatures with specific legal words and strips said signature automatically, responding to the sender that we did so. Joshua D. Drake regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES]
Not that I think that anyone owning both a law degree and a computer in 2007 should legitimately be able to plead innocence here. FAST Australia's lawyers are making themselves look like idiots, and the same for every other company tacking on such notices. I think the real bottom line here is we don't accept patches from idiots. Well the problem is, it isn't the guy that sent the patch that is the idiot. That guys has zero control over the matter, the signature is going to be tacked on at the MTA level. I talked to my attorneys about this problem (not specific to postgresql but in general) because my CPAs also have the same type of notice. My attorney's response was that it is all about disclosure and covering your butt. Not ours, but theirs. The idea being that they can say, Look we sent out the confidential disclosure, it isn't our fault the recipients didn't listen. Of course the joke here is, that the email went out on a public list and is now mirrored all over the world and harvested by every spammer on the planet ;) However, it may be a good idea to have our (SPI) attorney at least give us an official word on the matter. Thoughts? Sincerely, Joshua D. Drake regards, tom lane -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] WIP patch - INSERT-able log statements
FAST PostgreSQL wrote: On Fri, 16 Feb 2007 11:50, Tom Lane wrote: FAST PostgreSQL [EMAIL PROTECTED] writes: The second variable is of interest. We need to specify a table in the insert command. My preferred option is for the user to give one and he can create it if and when he wants to. The alternative is we decide the table name and make initdb to create one. Why not output the data in COPY format instead? That (a) eliminates the problem of needing to predetermine a destination table name, and (b) should be considerably faster to load than thousands of INSERT statements. Yeah, that was my initial idea too... But because the TODO item clearly mentions INSERT, I thought maybe there was some very specific reason for the output to be in INSERT stmts.. .. COPY would be a good option, but INSERT is probably what I would use as the default. The most use I see for this is something where I am tailing out the log and inserting live into a log db... Sincerely, Joshua D. Drake Rgds, Arul Shaji regards, tom lane This is an email from Fujitsu Australia Software Technology Pty Ltd, ABN 27 003 693 481. It is confidential to the ordinary user of the email address to which it was addressed and may contain copyright and/or legally privileged information. No one else may read, print, store, copy or forward all or any of it or its attachments. If you receive this email in error, please return to sender. Thank you. If you do not wish to receive commercial email messages from Fujitsu Australia Software Technology Pty Ltd, please email [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] \prompt for psql
Joshua D. Drake wrote: Alvaro Herrera wrote: Joshua D. Drake wrote: Peter Eisentraut wrote: Magnus Hagander wrote: That also requires a reasonable shell, which all platforms don't have... I think doing any sort of reasonable scripting around psql requires a reasonable shell. Or next someone will suggest implementing loops and conditionals in psql. ... Now that you mention it :) psql is a shell. It is the postgresql shell. I don't see any problem with continuing to extend the postgresql shell to a more functional platform that is independent. At least it'd help those poor people trying to do conditional COMMIT or ROLLBACK based on the transaction status. Maybe it's not such a bad idea. On the other hand, seeing how the history line numbers patch is still nowhere to be seen, I don't think we should be expecting you to send a patch ... ;-) No one would except it from me, I would just embed python ;) or perhaps accept Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] \prompt for psql
Peter Eisentraut wrote: Magnus Hagander wrote: That also requires a reasonable shell, which all platforms don't have... I think doing any sort of reasonable scripting around psql requires a reasonable shell. Or next someone will suggest implementing loops and conditionals in psql. ... Now that you mention it :) psql is a shell. It is the postgresql shell. I don't see any problem with continuing to extend the postgresql shell to a more functional platform that is independent. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] \prompt for psql
Alvaro Herrera wrote: Joshua D. Drake wrote: Peter Eisentraut wrote: Magnus Hagander wrote: That also requires a reasonable shell, which all platforms don't have... I think doing any sort of reasonable scripting around psql requires a reasonable shell. Or next someone will suggest implementing loops and conditionals in psql. ... Now that you mention it :) psql is a shell. It is the postgresql shell. I don't see any problem with continuing to extend the postgresql shell to a more functional platform that is independent. At least it'd help those poor people trying to do conditional COMMIT or ROLLBACK based on the transaction status. Maybe it's not such a bad idea. On the other hand, seeing how the history line numbers patch is still nowhere to be seen, I don't think we should be expecting you to send a patch ... ;-) No one would except it from me, I would just embed python ;) Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] [pgsql-patches] Phantom Command IDs, updated patch
Heikki Linnakangas wrote: Tom Lane wrote: Heikki Linnakangas [EMAIL PROTECTED] writes: I think the patch is ready. Please remove the PHANTOMCID_DEBUG define and ifdef blocks before applying. BTW, I don't care much for the terminology phantom cid ... there's nothing particularly phantom about them, seeing they get onto disk. Can anyone think of a better name? The best I can do offhand is merged cid or cid pair, which aren't inspiring. MultiCid, like the MultiXacts? Maybe not, they're quite different beasts... Alias cid? Mapped cid? Compressed cid? Hero cid? :) I'm happy with phantom cid myself. It sounds cool, and they are a bit phantom-like because the true meaning of a phantom cid is lost when the transaction ends. Phantom was also a super hero ;) Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Re: [pgsql-patches] [GENERAL] Corrupt database? 8.1/FreeBSD6.0
Bruce Momjian wrote: What is the status of this patch? Alvaro is currently out of town. He should be able to provide more info next week. Sincerely, Joshua D. Drake --- Alvaro Herrera wrote: Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Maybe we could forcibly activate the freeze mode on a template database? Might not be a bad idea. And even more to the point, forcibly disable analyze. Patch implementing this (albeit untested!) attached. I'll try to reproduce the problem without the patch, and then test with the patch applied. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. [ Attachment, skipping... ] ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-patches] guid/uuid datatype
Peter Eisentraut wrote: Gevik Babakhani wrote: So.. do we agree for uuid to be included in the core? I suggest that you read the discussion in the tsearch thread about figuring out how to make contrib modules more attractive. I don't see a reason why uuid has to be in the core, but I do see that there needs to be some centrally organized consolidation of the various existing attempts under a label of officiality. I think it would be more important to determine how we can get UUID in core. It is a known and accepted way of doing things in the marketplace and professional communities. It is time we stop fighting features for the sake of fighting features. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgsql-patches] guid/uuid datatype
The MAC-based generator function could also be included in the backend, actually: it just needs to take an argument of type macaddr. It would then be up to the user (and/or various pgfoundry and contrib/ modules) to find a way to determine the local machine's MAC address, which presumably can't be done reliably in a portable fashion. I assume we could just allow the MAC address or some unique idenfier to be specified in postgesql.conf. Well at that point why don't we allow it to be specified per database? ALTER DATABASE foo SET uuid_salt = :) That would be pretty cool, but I am sure most will shoot that down in flames :) Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too
Bruce Momjian wrote: Takayuki Tsunakawa wrote: From: Bruce Momjian [EMAIL PROTECTED] Yes, you are 100% correct that I had exceptions and errors confused. I have backed out the patch that used FormatMessage(), and instead of using a URL, the message is now: child process was terminated by exception %X See /include/ntstatus.h for a description of the hex value. When I search for /include/ntstatus.h, I get the Wine page first, so hopefully we can mark this item as completed. Thank you, Bruce-san. I agree. The Win32 port has always been done in small steps, sometimes to the left or right, but eventually forward. He feints to the left, he feints to the right, he ducks and POW! -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgsql-patches] guid/uuid datatype
Per previous discussion, the main problem with a uuid type is the new-uuid generator function, which tends to involve a bunch of not-so-portable assumptions and code. If we accept a uuid type in either core or contrib, all of a sudden those portability issues are our problem. I'd rather not deal with that. I'd be willing to accept a core uuid type sans generator function, but is that really all that useful? I think it would. There are plenty of client side libraries that generate uuid, at least we could provide a native type for them to use. A generator would be great too of course, but if they really need one they could use one of the pl languages for it. Sincerely, Joshua D. Drake regards, tom lane ---(end of broadcast)--- TIP 1: 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 -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgsql-patches] guid/uuid datatype
Joshua D. Drake wrote: Per previous discussion, the main problem with a uuid type is the new-uuid generator function, which tends to involve a bunch of not-so-portable assumptions and code. If we accept a uuid type in either core or contrib, all of a sudden those portability issues are our problem. I'd rather not deal with that. I'd be willing to accept a core uuid type sans generator function, but is that really all that useful? I think it would. There are plenty of client side libraries that generate uuid, at least we could provide a native type for them to use. A generator would be great too of course, but if they really need one they could use one of the pl languages for it. As a follow up to this both Java and Python have uuid generators that are built in. Which as we all know are both extremely portable languages. Sincerely, Joshua D. Drake Sincerely, Joshua D. Drake regards, tom lane ---(end of broadcast)--- TIP 1: 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 -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [pgsql-patches] [PATCHES] Tablespace for temporary objects and
On Thu, 2007-01-11 at 21:05 -0500, Jaime Casanova wrote: On 1/11/07, Albert Cervera Areny [EMAIL PROTECTED] wrote: Please, go on with that, I hadn't seen that problem. Indeed, I read Andrew answer to your question and I think it's a nice solution. yes... i'm always trying to kill flies with tanks... ;) Isn't that a little expensive on gas? i will use Andrew's suggestion... -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] COPY with no WAL, in certain circumstances
On Sat, 2007-01-06 at 11:05 -0500, Bruce Momjian wrote:
FYI, I am going need to add documentation in the COPY manual page or no
one will know about this performance enhancement.
I have some questions:
As discussed on -hackers, its possible to avoid writing any WAL at all
for COPY in these circumstances:
BEGIN;
CREATE TABLE foo..
COPY foo...
COMMIT;
What if I do this?
BEGIN;
CREATE TABLE foo...
INSERT INTO foo VALUES ('1');
COPY foo...
COMMIT;
?
E.g., what are the boundaries of ignoring the WAL?
Joshua D. Drake
BEGIN;
TRUNCATE foo..
COPY foo...
COMMIT;
The enclosed patch implements this, as discussed. There is no user
interface to enable/disable, just as with CTAS and CREATE INDEX; no
docs, just code comments.
This plays nicely with the --single-transaction option in psql to allow
fast restores/upgrades.
YMMV but disk bound COPY will benefit greatly from this patch, some
tests showing 100% gain. COPY is still *very* CPU intensive, so some
tests have shown negligible benefit, fyi, but that isn't the typical
case.
Applies cleanly to CVS HEAD, passes make check.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
[ Attachment, skipping... ]
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
---(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 with no WAL, in certain circumstances
BEGIN;
CREATE TABLE foo...
INSERT INTO foo VALUES ('1');
COPY foo...
COMMIT;
On ABORT, the entire table disappears, as well as the INSERT, so I don't
see any problem. I assume the INSERT is WAL logged.
No I don't see any problems, I am just trying to understand the
boundaries. E.g., is there some weird limitation where if I have any
values in the table before the copy (like the example above) that copy
will go through WAL.
Or in other words, does this patch mean that all COPY execution that is
within a transaction will ignore WAL?
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] COPY with no WAL, in certain circumstances
On Sat, 2007-01-06 at 16:41 -0200, Euler Taveira de Oliveira wrote: Simon Riggs wrote: As discussed on -hackers, its possible to avoid writing any WAL at all for COPY in these circumstances: Cool. The enclosed patch implements this, as discussed. There is no user interface to enable/disable, just as with CTAS and CREATE INDEX; no docs, just code comments. IMHO, this deserves an GUC parameter (use_wal_in_copy?). Because a lot of people use COPY because it's faster than INSERT but expects that it will be in WAL. The default would be use_wal_in_copy = true. That I don't think makes sense. A copy is an all or nothing option, if a copy fails in the middle the whole thing is rolled back. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate ---(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 with no WAL, in certain circumstances
Is there some technical reason that the INSERT statements need to use WAL in these scenarios? First, there's enough other overhead to an INSERT that you'd not save much percentagewise. Second, not using WAL doesn't come for free: the cost is having to fsync the whole table afterwards. So it really only makes sense for commands that one can expect are writing pretty much all of the table. I could easily see it being a net loss for individual INSERTs. What about multi value inserts? Just curious. Joshua D. Drake regards, tom lane -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] COPY with no WAL, in certain circumstances
On Sat, 2007-01-06 at 22:09 -0500, Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: cost is having to fsync the whole table afterwards. So it really only makes sense for commands that one can expect are writing pretty much all of the table. I could easily see it being a net loss for individual INSERTs. What about multi value inserts? Just curious. I wouldn't want the system to assume that a multi-VALUES insert is writing most of the table. Would you? The thing is reasonable for inserting maybe a few hundred or few thousand rows at most, and that's still small in comparison to typical tables. Good point. :) Joshua D. Drake regards, tom lane -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [PATCHES] SGML index build fix
On Sat, 2007-01-06 at 23:38 -0500, Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: The attached patch warns users when they create documentation output that has no index, and suggests re-running 'gmake'. This is just useless noise. If it could tell the difference between an up-to-date index and a not-up-to-date one, there might be some value to it ... but as-is I think it's just getting in the user's face. Everyone using these tools knows about the two-pass behavior. No, not everyone knows. In fact I would argue that most do not know. It isn't intuitive to the process. You *expect* that an index will be made. Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] wal_checksum = on (default) | off
Actually, I'm not seeing the use-case for a slave having a different setting from the master at all? My backup server is less reliable than the primary. My backup server is more reliable than the primary. Somehow, neither of these statements seem likely to be uttered by a sane DBA ... My backup server is actually my dev machine. My backup server is just a reporting machine. My backup machine is using SATA just because it is just an absolute emergency machine. My backups machine is also my web server. Real world dictates differently. Let's not forget that not every company can spend 100k on two identical machines, yet many companies can spend 50k + 5k for a backup machine based on Sata or secondary services. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 1: 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] [BUGS] BUG #2846: inconsistent and confusing
I get 'inf'. I am on BSD and just tested it on Fedora Core 2 and got 'inf' too. Ubuntu Edgy 64bit on Athlon 64X2 returns inf. Joshua D. Drake A slightly less radical proposal is to reject only the case where isinf(result) and neither input isinf(); and perhaps likewise with respect to NaNs. Uh, that's what the patch does for 'Inf': result = arg1 + arg2; CheckFloat4Val(result, isinf(arg1) || isinf(arg2)); I didn't touch 'Nan' because that is passed around as a value just fine --- it isn't created or tested as part of an overflow. -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 1: 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(es) to expose n_live_tuples and
On Tue, 2006-12-26 at 13:59 -0800, Glen Parker wrote: I'd love to see this back patched into 8.2.1 if possible. Probably not. We typically do not introduce new features into back releases. Sincerely, Joshua D. Drake Should I resubmit with new names? -Glen Bruce Momjian wrote: Is this something we want in 8.3? I am thinking visible/expired would be clearer terms. --- Glen Parker wrote: This patch consists of two c functions to expose n_live_tuples and n_dead_tuples, SQL functions to expose them to SQL land, and corresponding fields added to pg_stat_all_tables. This has been discussed in general. The purpose is to allow autovacuum-esq conditional vacuuming and clustering using SQL to discover the required stats. ---(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 -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 1: 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: [HACKERS] [PATCHES] Patch(es) to expose n_live_tuples and
The current terminology of live and dead is already used in many places in the documentation and in userspace; mostly around the need for maintainance of dead tuples within tables, reindex cleaning up dead pages, and even in the vacuum commands output (n dead tuples cannot be removed yet). Given this patch came from userland, istm people are comfortable enough with this terminology there is no need to change it. +1 -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] doc patch for savepoints
On Mon, 2006-11-27 at 17:48 -0500, Tom Lane wrote: Joseph Shraibman jks@selectacast.net writes: + para +Savepoints use shared memory. If you use many savepoints without releasing them, you +will run out of shared memory and you may see an error like this in your log: I do not see the point of this. Shall we put equivalent disclaimers into every single construct that consumes shared memory? Stating that it uses shared memory? Absolutely. Stating that you may run out? No, that is implicit in that shared memory is a static value made available to the operating system (well dynamic, but statically configured). Joshua D. Drake There is no such paragraph under LOCK TABLE, for example. regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] doc patch for savepoints
On Mon, 2006-11-27 at 17:58 -0500, Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: On Mon, 2006-11-27 at 17:48 -0500, Tom Lane wrote: I do not see the point of this. Shall we put equivalent disclaimers into every single construct that consumes shared memory? Stating that it uses shared memory? Absolutely. Stating that you may run out? No, ... Well, the fact that it uses shared memory is an uninteresting implementation detail --- at least, it's uninteresting until you run out. When/if that happens, ISTM the error message and HINT are plenty good enough to tell you what to do about it. If we tried to document every possible error message and appropriate corrective action for same the docs would become bloated to the point of unreadability. So to me the question is why this particular case deserves a paragraph of its own. I would agree that it likely does not need a paragraph on its own. Hmm... but a shared memory reference page? Something that says, What uses shared memory with PostgreSQL? That might be useful. Sincerely, Joshua D. Drake regards, tom lane -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] adminpack
Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: Here is adminpack... Applied with minor corrections (the .sql file is DATA not DATA_built, as you'd have found out if you'd tried make clean). Likewise for the pgrowlocks script. Noted, thanks. regards, tom lane -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(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
[PATCHES] adminpack
Hello, Here is adminpack... -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ? adminpack.diff ? adminpack.sql ? libadminpack.so.0.0 ? uninstall_adminpack.sql Index: Makefile === RCS file: /projects/cvsroot/pgsql/contrib/adminpack/Makefile,v retrieving revision 1.2 diff -c -r1.2 Makefile *** Makefile30 May 2006 21:34:15 - 1.2 --- Makefile29 Sep 2006 01:15:05 - *** *** 1,6 MODULE_big = adminpack PG_CPPFLAGS = -I$(libpq_srcdir) ! DATA_built = adminpack.sql DOCS = README.adminpack OBJS = adminpack.o --- 1,6 MODULE_big = adminpack PG_CPPFLAGS = -I$(libpq_srcdir) ! DATA_built = adminpack.sql uninstall_adminpack.sql DOCS = README.adminpack OBJS = adminpack.o DROP FUNCTION pg_catalog.pg_file_write(text, text, bool) ; DROP FUNCTION pg_catalog.pg_file_rename(text, text, text) ; DROP FUNCTION pg_catalog.pg_file_rename(text, text) ; DROP FUNCTION pg_catalog.pg_file_unlink(text) ; DROP FUNCTION pg_catalog.pg_logdir_ls() ; DROP FUNCTION pg_catalog.pg_file_read(text, bigint, bigint) ; DROP FUNCTION pg_catalog.pg_file_length(text) ; DROP FUNCTION pg_catalog.pg_logfile_rotate() ; ---(end of broadcast)--- TIP 1: 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] pgrowlocks
-- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ? adminpack.diff ? adminpack.sql ? libadminpack.so.0.0 ? uninstall_adminpack.sql Index: Makefile === RCS file: /projects/cvsroot/pgsql/contrib/adminpack/Makefile,v retrieving revision 1.2 diff -c -r1.2 Makefile *** Makefile30 May 2006 21:34:15 - 1.2 --- Makefile29 Sep 2006 01:15:05 - *** *** 1,6 MODULE_big = adminpack PG_CPPFLAGS = -I$(libpq_srcdir) ! DATA_built = adminpack.sql DOCS = README.adminpack OBJS = adminpack.o --- 1,6 MODULE_big = adminpack PG_CPPFLAGS = -I$(libpq_srcdir) ! DATA_built = adminpack.sql uninstall_adminpack.sql DOCS = README.adminpack OBJS = adminpack.o DROP FUNCTION pg_catalog.pg_file_write(text, text, bool) ; DROP FUNCTION pg_catalog.pg_file_rename(text, text, text) ; DROP FUNCTION pg_catalog.pg_file_rename(text, text) ; DROP FUNCTION pg_catalog.pg_file_unlink(text) ; DROP FUNCTION pg_catalog.pg_logdir_ls() ; DROP FUNCTION pg_catalog.pg_file_read(text, bigint, bigint) ; DROP FUNCTION pg_catalog.pg_file_length(text) ; DROP FUNCTION pg_catalog.pg_logfile_rotate() ; ---(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
[PATCHES] pgrowlocks(2)
Ooops :) -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ? libpgrowlocks.so.0.0 ? pgrowlocks.diff ? pgrowlocks.sql ? uninstall_pgrowlocks.sql Index: Makefile === RCS file: /projects/cvsroot/pgsql/contrib/pgrowlocks/Makefile,v retrieving revision 1.1 diff -c -r1.1 Makefile *** Makefile23 Apr 2006 01:12:58 - 1.1 --- Makefile29 Sep 2006 01:25:50 - *** *** 11,17 MODULE_big= pgrowlocks OBJS = $(SRCS:.c=.o) DOCS = README.pgrowlocks README.pgrowlocks.euc_jp ! DATA_built= pgrowlocks.sql ifdef USE_PGXS PGXS = $(shell pg_config --pgxs) --- 11,17 MODULE_big= pgrowlocks OBJS = $(SRCS:.c=.o) DOCS = README.pgrowlocks README.pgrowlocks.euc_jp ! DATA_built= pgrowlocks.sql uninstall_pgrowlocks.sql ifdef USE_PGXS PGXS = $(shell pg_config --pgxs) -- WE can just drop the type with a cascade SET search_path = public; DROP TYPE pgrowlocks CASCADE; ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Adding fulldisjunctions to the contrib
Dave Page wrote: -Original Message- From: [EMAIL PROTECTED] on behalf of Jonah H. Harris Sent: Sun 8/27/2006 3:24 AM To: Joshua D. Drake Cc: Andrew Dunstan; Bruce Momjian; Tzahi Fadida; pgsql-patches@postgresql.org Subject: Re: [PATCHES] Adding fulldisjunctions to the contrib It's odd, only 10 people have commented on this thread; 4 of which are core members, 2 in favor and 2 against. Yet, we're having an argument on why this wasn't included. Unless this is the new math, 2 vs. 2 seems like a tie to me. Y'know I was gonna check up on that because my recollection was that it was a 2/2 split as well, though I thought that was of people who made their view clear rather than just -core (whose opinion in this case is no more important than any of the other long time contributors imho). Don't suppose you noted the views of the other 6? IIRC some of the rejection points, was the code: 1. Is not quite complete 2. Does not follow postgresql style guidelines Those two items make it impossible to include Full disjunctions in core. I believe those two points were made by Tom but I can't find his response so if I am on crack -- I apologize in advance. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Adding fulldisjunctions to the contrib
this is inaccurate, irresponsible and insulting to those of us who spend time maintaining pgfoundry. It is not a graveyard. Plenty of stuff outside the core gets included in packaged distributions - just see for example what goes into the Windows distro, or the packages that CP distributes. Jonah, Your attitude has been lacking about this whole thing, as has a lot of other people. PgFoundry is the official sub project site for PostgreSQL. It is not a graveyard, projects on PgFoundry should receive full advocacy and promotion about their abilities and their linkage PostgreSQL. If we spent half as much time promoting and helping the various sub project succeed as we doing whining on this list, we would be far more dominant in the industry then we are. I am sick of all the moaning that goes on, with this list about -- oh please, we need this in core. It is a crock we have a huge repository of PostgreSQL projects that are not in core and this attitude is detrimental and negative to all who are involved with those projects. When full disjunctons is ready, I am sure it will be considered for core. It currently is not and pgFoundry is the perfect place for until until then. We can still promote and announce we have a full disjunctions implementation, just as we can advertise we have full text indexing. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 1: 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] Some minor changes to pgbench
Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: * The schema now uses foreign keys to more accurately reflect a finacial DDL Addition of foreign key checking will certainly impact performance significantly. That is kind of the point. Without foreign keys it is a flawed test because you wouldn't be running in production without them and thus you can't bench without them. * The history table now has a primary key that uses a serial Ditto. Again, part of the point :) * The respective balance columns have been increased to int8 to deal with larger values Ditto. This was done because you can easily break pgbench without the increase in data type. pgbench -c 850 -t 1000 pgbench gave a stream of errors like this before ending: Client 18 aborted in state 8: ERROR: integer out of range Client 429 aborted in state 8: ERROR: integer out of range Client 168 aborted in state 8: ERROR: integer out of range PG error log showed: 2006-08-22 15:45:19 PDT-[local]STATEMENT: UPDATE branches SET bbalance = bbalance + 4209228 WHERE bid = 679; 2006-08-22 15:45:19 PDT-[local]ERROR: integer out of range * Initalization will be done in a new schema/namespace, pgbench will exit if this schema/namespace exists OK, maybe that doesn't matter. Yeah I did it just so we wouldn't stomp on somebody on accident. * The new DDL should allow both Mammoth Replicator and Slony to be tested using pgbench (at least basic replication) Erm ... exactly why couldn't you do that before? history was missing a primary key. It could be done before. I just removed a step in getting it to work. pgbench doesn't have all that many things to recommend it, but what it does have is that it's been a stable testbed across quite a few PG releases. Arbitrarily whacking around the tested functionality will destroy that continuity. Well to be fair, I wasn't doing it arbitrarily. I had a specific purpose which was to have it use a schema that would be closer to a production schema, without breaking existing behavior. This patch does that :) I fell into this trap before myself ... I have a local copy of pgbench that produces TPS numbers quite a lot better than the standard pgbench, against exactly the same server. What's wrong with that picture? Well I think we all agree that some of the behavior of pgbench has been weird. Sincerely, Joshua D. Drake regards, tom lane -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Some minor changes to pgbench
Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: Tom Lane wrote: Addition of foreign key checking will certainly impact performance significantly. That is kind of the point. Without foreign keys it is a flawed test because you wouldn't be running in production without them and thus you can't bench without them. pgbench is not about reality, though. If we can't rely on it to give consistent results across versions then I don't think it's useful at all. There are many other benchmarks you can run that do speak to reality (eg OSDL's work). Would it be worthwhile to add a switch so that the foreign key test is only used if they use the switch in conjunction with a -i? Joshua D. Drake regards, tom lane -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
