[PATCHES] note on dropped columns in pg_attribute
I didn't see it documented anywhere that a 0 in attypid of pg_attribute,
and given the note on the need to match pg_type lest failure seems to
warrant the mention.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Index: src/include/catalog/pg_attribute.h
===
RCS file: /projects/cvsroot/pgsql-server/src/include/catalog/pg_attribute.h,v
retrieving revision 1.104
diff -c -r1.104 pg_attribute.h
*** src/include/catalog/pg_attribute.h 4 Aug 2003 02:40:11 - 1.104
--- src/include/catalog/pg_attribute.h 4 Sep 2003 22:30:44 -
***
*** 50,56
* defines the data type of this attribute (e.g. int4). Information
* in that instance is redundant with the attlen, attbyval, and
* attalign attributes of this instance, so they had better match or
! * Postgres will fail.
*/
Oid atttypid;
--- 50,57
* defines the data type of this attribute (e.g. int4). Information
* in that instance is redundant with the attlen, attbyval, and
* attalign attributes of this instance, so they had better match or
! * Postgres will fail. An entry of 0 signifies a dropped column and
! * will have no match.
*/
Oid atttypid;
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] note on dropped columns in pg_attribute
On Friday 05 September 2003 16:24, Peter Eisentraut wrote:
Robert Treat writes:
I didn't see it documented anywhere that a 0 in attypid of pg_attribute,
and given the note on the need to match pg_type lest failure seems to
warrant the mention.
A column is dropped if and only if attisdropped is true.
Right. I didn't mean to imply otherwise. That first line should have read I
didn't see it documented anywhere that a 0 in attypid of pg_attribute is OK
with dropped columns. My only point was that in the notes it says that
attypid is the OID in pg_type, and that information in that table must match
information in this table else PostgreSQL will fail. However that's not
neccessarily true for dropped columns where there is no match cause attypid
will be 0. Are there other cases where it can be set to 0?
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
[PATCHES] akward wording in autovacuum README
Change some awkward wording in the pg_autovacuum README file. I really
only read this because of Niel :-)
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Index: README.pg_autovacuum
===
RCS file: /projects/cvsroot/pgsql-server/contrib/pg_autovacuum/README.pg_autovacuum,v
retrieving revision 1.3
diff -c -r1.3 README.pg_autovacuum
*** README.pg_autovacuum 13 Sep 2003 16:26:17 - 1.3
--- README.pg_autovacuum 8 Oct 2003 18:04:38 -
***
*** 35,41
pg_autovacuum requires that the statistics system be enabled and
reporting row level stats. The overhead of the stats system has been
! shown to be significant costly under certain workloads. For instance,
a tight loop of queries performing select 1 was found to run nearly
30% slower when stats were enabled. However, in practice, with more
realistic workloads, the stats system overhead is usually nominal.
--- 35,41
pg_autovacuum requires that the statistics system be enabled and
reporting row level stats. The overhead of the stats system has been
! shown to have a significant cost under certain workloads. For instance,
a tight loop of queries performing select 1 was found to run nearly
30% slower when stats were enabled. However, in practice, with more
realistic workloads, the stats system overhead is usually nominal.
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
[PATCHES] beta5 references beta4 in INSTALL
better late than never?
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Index: INSTALL
===
RCS file: /projects/cvsroot/pgsql-server/INSTALL,v
retrieving revision 1.91
diff -c -r1.91 INSTALL
*** INSTALL 4 Oct 2003 03:14:13 - 1.91
--- INSTALL 23 Oct 2003 12:21:34 -
***
*** 170,176
if you need to do this.
To make the backup, you can use the pg_dumpall command from the
version you are currently running. For best results, however, try
!to use the pg_dumpall command from PostgreSQL 7.4beta4, since
this version contains bug fixes and improvements over older
versions. While this advice might seem idiosyncratic since you
haven't installed the new version yet, it is advisable to follow
--- 170,176
if you need to do this.
To make the backup, you can use the pg_dumpall command from the
version you are currently running. For best results, however, try
!to use the pg_dumpall command from PostgreSQL 7.4beta5, since
this version contains bug fixes and improvements over older
versions. While this advice might seem idiosyncratic since you
haven't installed the new version yet, it is advisable to follow
***
*** 196,202
like this:
mv /usr/local/pgsql /usr/local/pgsql.old
!After you have installed PostgreSQL 7.4beta4, create a new database
directory and start the new server. Remember that you must execute
these commands while logged in to the special database user account
(which you already have if you are upgrading).
--- 196,202
like this:
mv /usr/local/pgsql /usr/local/pgsql.old
!After you have installed PostgreSQL 7.4beta5, create a new database
directory and start the new server. Remember that you must execute
these commands while logged in to the special database user account
(which you already have if you are upgrading).
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [PATCHES] minor cleanup in plpgsql.sgml
Sorry Neil. I thought I recalled you submitting a similar patch, but
must have missed it in the archives and didn't see the change reflected
in cvs so assmeme'd that your change was in a different place.. :-(
Robert Treat
On Tue, 2003-11-25 at 14:04, Neil Conway wrote:
Robert Treat [EMAIL PROTECTED] writes:
Marcos Truchado [EMAIL PROTECTED] reported this on -docs
yesterday.
I submitted a patch for this typo to -patches 5 days ago.
-Neil
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [PATCHES] minor cleanup in plpgsql.sgml
The reported correction was removing the superfluous full_name varchar (which
Neil Conway also reported a few days back). When i was rewriting the
function, I subconsciously switched the SELECT INTO statement to the (IMHO)
more legible syntax, though nothing was wrong with the previous version of
that statement.
Robert Treat
On Tuesday 25 November 2003 20:30, Christopher Kings-Lynne wrote:
Ummm - surely the original was correct?
Chris
Robert Treat wrote:
Marcos Truchado [EMAIL PROTECTED] reported this on -docs
yesterday.
Robert Treat
Index: plpgsql.sgml
===
RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/plpgsql.sgml,v
retrieving revision 1.29
diff -c -r1.29 plpgsql.sgml
*** plpgsql.sgml12 Nov 2003 22:47:47 - 1.29
--- plpgsql.sgml25 Nov 2003 14:12:50 -
***
*** 986,994
programlisting
DECLARE
users_rec RECORD;
- full_name varchar;
BEGIN
! SELECT INTO users_rec * FROM users WHERE user_id=3;
IF users_rec.homepage IS NULL THEN
-- user entered no homepage, return http://;
--- 986,993
programlisting
DECLARE
users_rec RECORD;
BEGIN
! SELECT * FROM users WHERE user_id=3 INTO users_rec;
IF users_rec.homepage IS NULL THEN
-- user entered no homepage, return http://;
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] FAQ updates
I think I can work that up. Out of curiosity are the plain text files
generated from the html files? Also I noticed that not all plain text
FAQ's have html FAQ's associated with them... is that by design or just
the fact that no one has bothered to bring them up to speed?
Robert Treat
On Fri, 2004-03-19 at 10:56, Bruce Momjian wrote:
Can I get HTML diffs against contrib/src/FAQ.html?
---
Robert Treat wrote:
Updated a few FAQ entries.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
[ Attachment, skipping... ]
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [PATCHES] [HACKERS] Is trust really a good default?
On Tue, 2004-07-13 at 17:44, Bruce Momjian wrote:
Magnus Hagander wrote:
not to mention the
more basic problem that the comments will now be wrong.
That, however, it is correct :-( Sloppy.
How about a text along the line of:
CAUTION: Configuring the system for trust authentication allows any
local user to connect using any PostgreSQL user name, including the
superuser, over either Unix domain sockets or TCP/IP. If you are on
a multiple-user machine, this is probably not good. Change it to use
something other than trust authentication.
Or something along that line? Since it would no longer actually be
default. Or do we want something like On some installations, the
default is...?
Woh, I didn't think we agreed that the default would change from
'trust', only that we would now emit a warning and allow other
authentication methods to be specified at initdb time.
I sure hope not (and that was my understanding as well)
Incidentally that warning is a little misleading since it isn't just
trust authentication that allows the wide open connections, but the
combo of all users / all dbs / trust that does it. For example on one
of my development machine I have a guest user who only has read access
to a specific database from a limited subnet, but with trust
authentication since random people inside the company will sometimes
want to take a look at what I am cooking up. For my needs I use the
superuser account who can access all databases but must come through
ident on a unix socket. Different strokes for different folks eh?
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[PATCHES] minor doc change
This patch makes mention to use the newer pg_dump when migrating, as suggested
by a few folks.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Index: backup.sgml
===
RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/backup.sgml,v
retrieving revision 2.47
diff -c -r2.47 backup.sgml
*** backup.sgml 29 Aug 2004 21:08:47 - 2.47
--- backup.sgml 30 Sep 2004 05:53:53 -
***
*** 946,962
change between major releases of productnamePostgreSQL/ (where
the number after the first dot changes). This does not apply to
different minor releases under the same major release (where the
!number after the second dot changes); these always have compatible
storage formats. For example, releases 7.0.1, 7.1.2, and 7.2 are
not compatible, whereas 7.1.1 and 7.1.2 are. When you update
between compatible versions, you can simply replace the executables
and reuse the data area on disk. Otherwise you need to
quoteback up/ your data and quoterestore/ it on the new
!server, using applicationpg_dump/. (There are checks in place
!that prevent you from doing the wrong thing, so no harm can be done
!by confusing these things.) The precise installation procedure is
!not the subject of this section; those details are in xref
!linkend=installation.
/para
para
--- 946,964
change between major releases of productnamePostgreSQL/ (where
the number after the first dot changes). This does not apply to
different minor releases under the same major release (where the
!number after the second dot changes); these should always have compatible
storage formats. For example, releases 7.0.1, 7.1.2, and 7.2 are
not compatible, whereas 7.1.1 and 7.1.2 are. When you update
between compatible versions, you can simply replace the executables
and reuse the data area on disk. Otherwise you need to
quoteback up/ your data and quoterestore/ it on the new
!server, using applicationpg_dump/. (It is strongly recommended that you
!use the applicationpg_dump/ program from the newer version of
!productnamePostgreSQL/ to take advantage of any enhancements that may
!have occured. There are checks in place that prevent you from doing the
!wrong thing, so no harm can be done by confusing these things.) The precise
!installation procedure is not the subject of this section; those details
!are in xref linkend=installation.
/para
para
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
[PATCHES] FAQ update
added question on website development
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Index: FAQ.html
===
RCS file: /projects/cvsroot/pgsql/doc/src/FAQ/FAQ.html,v
retrieving revision 1.227
diff -c -r1.227 FAQ.html
*** FAQ.html 1 Sep 2004 03:28:15 - 1.227
--- FAQ.html 29 Oct 2004 01:08:42 -
***
*** 43,48
--- 43,49
SMALLDBMS/SMALLs?BR
A href=#1.151.15/A) How can I financially assist
PostgreSQL?BR
+ A href=#1.161.16/A) I'd like to update the PostgreSQL website, what do I need to do?BR
H2 align=centerUser Client Questions/H2
***
*** 503,508
--- 504,512
it to our advocacy site at a href=http://advocacy.postgresql.org;
http://advocacy.postgresql.org/a./P
+ H4A name=1.161.16/A) I'd like to update the PostgreSQL website, what do I need to do?/H4
+
+ PPostgreSQL website development is discussed on the [EMAIL PROTECTED] mailing list. The is a project page where the source code is available at a href=http://gborg.postgresql.org/project/pgweb/projdisplay.php;http://gborg.postgresql.org/project/pgweb/projdisplay.php/a, the code for the next version of the website is under the portal module. You will also find code for the techdocs website if you would like to contribute to that. A temporary todo list for current website development issues is available at a href=http://xzilla.postgresql.org/todo;http://xzilla.postgresql.org/todo/a/P
H2 align=centerUser Client Questions/H2
---(end of broadcast)---
TIP 8: explain analyze is your friend
[PATCHES] Give the TODO list a little more verbose explanation
People seem to get confused about just what the TODO list is, this patch gives
a more verbose explanation of how it works.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Index: TODO
===
RCS file: /projects/cvsroot/pgsql/doc/TODO,v
retrieving revision 1.1400
diff -r1.1400 TODO
4d3
#A hyphen (-) marks changes that will appear in the upcoming 8.1 release.#
6c5
Bracketed items [] have more detail.
---
This is a list of items that the major developers of PostgreSQL have agreed need to be addressed. An items appearance on this list does not mean it is being actively developed; look for items with a name following them to see items that have been claimed for active development, otherwise please post a message to the pgsql-hackers mailing list if you are interested in contributing code for a specific item. If an item has brackets [], there is more detail available, so be sure to read that before posting. Finally, items with a hyphen (-) mark changes that have completed and will appear in the 8.1 release.
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] Give the TODO list a little more verbose explanation
This is certainly nicer than what I had. This seems to be mostly a copy/paste
change, but if I need to submit a new patch lmk.
Robert Treat
On Saturday 13 November 2004 03:57, Gavin Sherry wrote:
Robert,
I think there are some mistakes with your addition. Here's a reworked
paragraph:
---
This is a list of items which have been put to or discussed by
contributors to the project. Many items have been discussed extensively on
the mailing lists, the archives of which can be found here:
http://archives.postgresql.org. Appearance on this list means that at
least one major contributor considered the idea worth further
investigation or implementation.
As such, an item's appearance on this list does not mean it is being
actively developed: look for items with a name following them to see items
that have been claimed for active development
If you are interested in contributing code for a specific item, first
consult the developer's FAQ at
http://developer.postgresql.org/readtext.php?src/FAQ/FAQ_DEV.html+Developer
s-FAQ
If an item has brackets [], there is more detail available, so be sure
to read that before posting.
Items with a hyphen (-) mark changes that have completed and will appear
in the 8.1 release.
---
Gavin
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[PATCHES] default timezone in postgresql.conf
Changes the doc's to reflect what the user will find as default.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Index: runtime.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/runtime.sgml,v
retrieving revision 1.295
diff -c -r1.295 runtime.sgml
*** runtime.sgml 5 Dec 2004 20:05:47 - 1.295
--- runtime.sgml 13 Dec 2004 05:39:01 -
***
*** 3150,3157
listitem
para
Sets the time zone for displaying and interpreting time
! stamps. The default is to use whatever the system environment
! specifies as the time zone. See xref
linkend=datatype-datetime for more information.
/para
/listitem
--- 3150,3157
listitem
para
Sets the time zone for displaying and interpreting time
! stamps. The default is 'unknown', which means to use whatever
! the system environment specifies as the time zone. See xref
linkend=datatype-datetime for more information.
/para
/listitem
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
[PATCHES] small typo in create user --help
I guess this has to be saved for 8.1... shame.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Index: createuser.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/scripts/createuser.c,v
retrieving revision 1.14
diff -c -r1.14 createuser.c
*** createuser.c 29 Aug 2004 04:13:03 - 1.14
--- createuser.c 14 Dec 2004 01:45:10 -
***
*** 246,252
printf(_( -D, --no-createdb user cannot create databases\n));
printf(_( -P, --pwpromptassign a password to new user\n));
printf(_( -E, --encrypted encrypt stored password\n));
! printf(_( -N, --unencrypted do no encrypt stored password\n));
printf(_( -i, --sysid=SYSID select sysid for new user\n));
printf(_( -e, --echoshow the commands being sent to the server\n));
printf(_( -q, --quiet don't write any messages\n));
--- 246,252
printf(_( -D, --no-createdb user cannot create databases\n));
printf(_( -P, --pwpromptassign a password to new user\n));
printf(_( -E, --encrypted encrypt stored password\n));
! printf(_( -N, --unencrypted do not encrypt stored password\n));
printf(_( -i, --sysid=SYSID select sysid for new user\n));
printf(_( -e, --echoshow the commands being sent to the server\n));
printf(_( -q, --quiet don't write any messages\n));
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] Continue transactions after errors in psql
On Tuesday 25 January 2005 22:07, Greg Sabino Mullane wrote:
Attached is a patch that takes advantage of savepoints to enable
transactions to continue even after errors in psql. The name of it
is \reseterror, and it is off by default. It's backwards compatible,
and allows things like this to work on 8.0 and up servers:
\reseterror
BEGIN;
DELETE FROM foobar;
INSERT INTO foobar(a) VALUES(1);
ISNER INTO foobar(a) VALUES(2);
INSERT INTO foobar(a) VALUES(3);
COMMIT;
Doing a SELECT(a) FROM foobar will show two values, 1 and 3. This
is a great help for those of us that tend to type typos into our
psql session, and end up cursing as we have to restart our current
transaction. :)
I've been testing this patch and found the following bug:
test=# \reseterror
Reset error is on.
test=# begin;
BEGIN
test=# select * from t;
c
---
1
(1 row)
test=# delete from t;
DELETE 1
test=# select * from tt;
ERROR: relation tt does not exist
ERROR: relation tt does not exist
test=# select * from t;
c
---
(0 rows)
test=# commit;
COMMIT
ERROR: RELEASE SAVEPOINT may only be used in transaction blocks
ERROR: RELEASE SAVEPOINT may only be used in transaction blocks
I've attached a revised patch which fixes the problem, however I'm sure there
is a better way. Thanks to Neil for putting up with me on irc :-)
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Index: command.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/psql/command.c,v
retrieving revision 1.139
diff -c -r1.139 command.c
*** command.c 1 Jan 2005 05:43:08 - 1.139
--- command.c 28 Jan 2005 06:42:03 -
***
*** 646,651
--- 646,672
puts(gettext(Query buffer reset (cleared).));
}
+ /* \reseterror -- use savepoints to make transaction errors recoverable */
+ else if (strcmp(cmd, reseterror) == 0)
+ {
+ if (pset.sversion 8)
+ {
+ printf(gettext(The server version (%d) does not support savepoints.\n),
+ pset.sversion);
+ }
+ else
+ {
+ pset.reseterror = !pset.reseterror;
+ if (!quiet)
+ {
+ if (pset.reseterror)
+ puts(gettext(Reset error is on.));
+ else
+ puts(gettext(Reset error is off.));
+ }
+ }
+ }
+
/* \s save history in a file or show it on the screen */
else if (strcmp(cmd, s) == 0)
{
Index: common.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/psql/common.c,v
retrieving revision 1.95
diff -c -r1.95 common.c
*** common.c 1 Jan 2005 05:43:08 - 1.95
--- common.c 28 Jan 2005 06:42:03 -
***
*** 941,950
bool
SendQuery(const char *query)
{
! PGresult *results;
TimevalStruct before,
after;
bool OK;
if (!pset.db)
{
--- 941,951
bool
SendQuery(const char *query)
{
! PGresult *results, *res;
TimevalStruct before,
after;
bool OK;
+ PGTransactionStatusType tstatus;
if (!pset.db)
{
***
*** 973,979
SetCancelConn();
! if (PQtransactionStatus(pset.db) == PQTRANS_IDLE
!GetVariableBool(pset.vars, AUTOCOMMIT)
!command_no_begin(query))
{
--- 974,982
SetCancelConn();
! tstatus = PQtransactionStatus(pset.db);
!
! if (PQTRANS_IDLE == tstatus
!GetVariableBool(pset.vars, AUTOCOMMIT)
!command_no_begin(query))
{
***
*** 987,992
--- 990,1010
}
PQclear(results);
}
+ else {
+ /* If we are in error recovery mode and inside a transaction,
+ possibly issue a temporary savepoint */
+ if (PQTRANS_INTRANS==tstatus pset.reseterror) {
+ res = PQexec(pset.db, SAVEPOINT psql_savepoint);
+ if (PQresultStatus(res) != PGRES_COMMAND_OK)
+ {
+ psql_error(%s, PQerrorMessage(pset.db));
+ PQclear(res);
+ ResetCancelConn();
+ return false;
+ }
+ PQclear(res);
+ }
+ }
if (pset.timing)
GETTIMEOFDAY(before);
***
*** 1001,1008
/* but printing results isn't: */
if (OK)
! OK = PrintQueryResults(results);
!
PQclear(results);
/* Possible microtiming output */
--- 1019,1049
/* but printing results isn't: */
if (OK)
! OK = PrintQueryResults(results);
!
! /* If in error recovery mode, release the savepoint */
!
! if (PQTRANS_INTRANS==tstatus pset.reseterror) {
! tstatus = PQtransactionStatus(pset.db);
!
! if (PQTRANS_INERROR==tstatus)
! res = PQexec(pset.db, ROLLBACK TO psql_savepoint);
! else if (PQTRANS_IDLE==tstatus)
! /* COMMITing leaves us in PQTRANS_IDLE so we can't release the save point here */
! res = PQexec(pset.db, SELECT 1);
! else
! res = PQexec(pset.db, RELEASE psql_savepoint);
!
! if (PQresultStatus(res) != PGRES_COMMAND_OK)
! {
! psql_error(%s, PQerrorMessage(pset.db));
! PQclear(res);
! ResetCancelConn();
! return false
Re: [PATCHES] Continue transactions after errors in psql
On Fri, 2005-01-28 at 04:46, Christopher Kings-Lynne wrote:
I've attached a revised patch which fixes the problem, however I'm sure
there
is a better way. Thanks to Neil for putting up with me on irc :-)
How about calling the savepoint pg_psql_savepoint instead, that way it
follows our 'don't begin things with pg_' philosophy.
I was actually thinking of calling it something like
pg_xact-start-time thinking that would be pretty unique within a
transaction, though having a specific documented name seemed ok too.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[PATCHES] Update to download info in install docs
Inspired by comments from steve [EMAIL PROTECTED], adds a few urls for
more download options.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Index: installation.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/installation.sgml,v
retrieving revision 1.229
diff -c -r1.229 installation.sgml
*** installation.sgml 23 Jan 2005 00:30:18 - 1.229
--- installation.sgml 28 Mar 2005 13:33:31 -
***
*** 326,333
para
The productnamePostgreSQL/ version; sources can be obtained by
anonymous FTP from ulink
!url=ftp://ftp.postgresql.org/pub/source/vversion;/postgresql-version;.tar.gz;/ulink.
!Use a mirror if possible. After you have obtained the file, unpack it:
screen
userinputgunzip postgresql-version;.tar.gz/userinput
userinputtar xf postgresql-version;.tar/userinput
--- 326,336
para
The productnamePostgreSQL/ version; sources can be obtained by
anonymous FTP from ulink
!url=ftp://ftp.postgresql.org/pub/source/vversion;/postgresql-version;.tar.gz;/ulink
!or one of our numerous ulink url=http://www.postgresql.org/download/mirrors-ftp;mirror sites/ulink
!available throughout the world. Other download options can be found on our
!ulink url=http://www.postgresql.org/download/;website/ulink. After you
!have obtained the file, unpack it:
screen
userinputgunzip postgresql-version;.tar.gz/userinput
userinputtar xf postgresql-version;.tar/userinput
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[PATCHES] update some urls
This patch updates a number of urls in a number of files. Most are just
poinitng to the TODO list within the main website.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
? url_update.patch
Index: doc/src/FAQ/FAQ.html
===
RCS file: /projects/cvsroot/pgsql/doc/src/FAQ/FAQ.html,v
retrieving revision 1.294
diff -c -r1.294 FAQ.html
*** doc/src/FAQ/FAQ.html 15 Mar 2005 22:38:23 - 1.294
--- doc/src/FAQ/FAQ.html 10 Apr 2005 04:29:24 -
***
*** 275,281
missing features?/H4
PPostgreSQL supports an extended subset of SMALLSQL/SMALL-92.
! See our A href=http://developer.PostgreSQL.org/todo.php;TODO/A
list for known bugs, missing features, and future plans./P
H4A name=1.101.10/A) How can I learn
--- 275,281
missing features?/H4
PPostgreSQL supports an extended subset of SMALLSQL/SMALL-92.
! See our A href=http://www.postgresql.org/docs/faqs.TODO.html;TODO/A
list for known bugs, missing features, and future plans./P
H4A name=1.101.10/A) How can I learn
Index: doc/src/FAQ/FAQ_DEV.html
===
RCS file: /projects/cvsroot/pgsql/doc/src/FAQ/FAQ_DEV.html,v
retrieving revision 1.94
diff -c -r1.94 FAQ_DEV.html
*** doc/src/FAQ/FAQ_DEV.html 14 Mar 2005 03:07:25 - 1.94
--- doc/src/FAQ/FAQ_DEV.html 10 Apr 2005 04:29:26 -
***
*** 124,131
H3A name=1.31.3/A) What areas need work?/H3
Outstanding features are detailed in the TODO list. This is located
in Idoc/TODO/I in the source distribution or at A href=
! http://developer.postgresql.org/todo.php;
! http://developer.postgresql.org/todo.php/A.
PYou can learn more about these features by consulting the
--- 124,131
H3A name=1.31.3/A) What areas need work?/H3
Outstanding features are detailed in the TODO list. This is located
in Idoc/TODO/I in the source distribution or at A href=
! http://www.postgresql.org/docs/faqs.TODO.html;
! http://www.postgresql.org/docs/faqs.TODO.html/A.
PYou can learn more about these features by consulting the
Index: doc/src/FAQ/FAQ_brazilian.html
===
RCS file: /projects/cvsroot/pgsql/doc/src/FAQ/FAQ_brazilian.html,v
retrieving revision 1.8
diff -c -r1.8 FAQ_brazilian.html
*** doc/src/FAQ/FAQ_brazilian.html 11 Mar 2005 21:46:54 - 1.8
--- doc/src/FAQ/FAQ_brazilian.html 10 Apr 2005 04:29:27 -
***
*** 289,295
H4A name=1.91.9/A) Como eu posso saber quais satilde;o os bugs conhecidos ou caracteriacute;sticas ausentes?/H4
PPostgreSQL suporta um subconjunto extendido do SMALLSQL/SMALL-92.
! Veja a nossa lista de afazeres (A href=http://developer.PostgreSQL.org/todo.php;TODO/A) para saber sobre bugs conhecidos, caracteriacute;sticas ausentes e planos futuros./P
H4A name=1.101.10/A) Como eu posso aprender SMALLSQL/SMALL?/H4
--- 289,295
H4A name=1.91.9/A) Como eu posso saber quais satilde;o os bugs conhecidos ou caracteriacute;sticas ausentes?/H4
PPostgreSQL suporta um subconjunto extendido do SMALLSQL/SMALL-92.
! Veja a nossa lista de afazeres (A href=http://www.postgresql.org/docs/faqs.TODO.html;TODO/A) para saber sobre bugs conhecidos, caracteriacute;sticas ausentes e planos futuros./P
H4A name=1.101.10/A) Como eu posso aprender SMALLSQL/SMALL?/H4
Index: doc/src/FAQ/FAQ_czech.html
===
RCS file: /projects/cvsroot/pgsql/doc/src/FAQ/FAQ_czech.html,v
retrieving revision 1.4
diff -c -r1.4 FAQ_czech.html
*** doc/src/FAQ/FAQ_czech.html 11 Mar 2005 21:46:54 - 1.4
--- doc/src/FAQ/FAQ_czech.html 10 Apr 2005 04:29:30 -
***
*** 283,289
H4A name=1.91.9/A) Kde najdu seznam známých chyb nebo nepodporovaných vlastností?/H4
PPostgreSQL podporuje roz¹íøenou podmno¾inu SMALLSQL-92/SMALL. V na¹em
!A href=http://developer.PostgreSQL.org/todo.php;TODO/A
najdete seznam známých chyb, chybìjících vlastností a seznam vlastností,
které budou do systému implementovány v budoucnu (vèetnì priorit)./P
--- 283,289
H4A name=1.91.9/A) Kde najdu seznam známých chyb nebo nepodporovaných vlastností?/H4
PPostgreSQL podporuje roz¹íøenou podmno¾inu SMALLSQL-92/SMALL. V na¹em
!A href=http://www.postgresql.org/docs/faqs.TODO.html;TODO/A
najdete seznam známých chyb, chybìjících vlastností a seznam vlastností,
které budou do systému implementovány v budoucnu (vèetnì priorit)./P
Index: doc/src/FAQ/FAQ_farsi.html
===
RCS file: /projects/cvsroot/pgsql/doc/src/FAQ/FAQ_farsi.html,v
retrieving revision 1.2
diff -c -r1.2 FAQ_farsi.html
*** doc/src/FAQ/FAQ_farsi.html 1 Jan 2005 22:14
Re: [HACKERS] [PATCHES] Continue transactions after errors in psql
On Tue, 2005-04-26 at 10:28, Tom Lane wrote:
Greg Sabino Mullane [EMAIL PROTECTED] writes:
To reiterate my opinion, I think the behavior should be the same
for interactive and non-interactive sessions. Not only will it
prevent nasty surprises, but unless we make a third 'setting',
there will be no way to enable this in non-interactive scripts,
which is something that I would want to be able to do.
I'm finding it hard to visualize a non-interactive script making
any good use of such a setting. Without a way to test whether
you got an error or not, it would amount to an ignore errors
within transactions mode, which seems a pretty bad idea.
Can you show a plausible use-case for such a thing?
I plan to use it in scripts that push site meta-data out to our test
servers, where the list of sites are all different so any static data
dump is bound to fail on some foreign key checks (but I don't care which
ones fail as long as some go over).
I'm sure others can come up with different scenarios, but more
importantly is I don't see a good reason to treat this setting different
from all others and explicitly forbid this use from people, especially
when I can imagine people coming from other dbs where this behavior is
more common who might in fact expect it to work this way.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
[PATCHES] Problem with Create Domain example
The example given in create domain seems to be broken. ISTM it requires some
extra escaping to be usable (at least in my goings on today it sure was, and
I the entries in pg_constraint sure seem to indicate this as well). I
suggest that the examples should be updated as per the following patch.
Oh.. and Andrew @ Supernews had nothing to do with this ;-)
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Index: create_domain.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/ref/create_domain.sgml,v
retrieving revision 1.20
diff -c -r1.20 create_domain.sgml
*** create_domain.sgml 4 Jan 2005 00:39:53 - 1.20
--- create_domain.sgml 30 Apr 2005 22:06:33 -
***
*** 167,174
programlisting
CREATE DOMAIN us_postal_code AS TEXT
CHECK(
!VALUE ~ '^\d{5}$'
! OR VALUE ~ '^\d{5}-\d{4}$'
);
CREATE TABLE us_snail_addy (
--- 167,174
programlisting
CREATE DOMAIN us_postal_code AS TEXT
CHECK(
!VALUE ~ '^\\d{5}$'
! OR VALUE ~ '^\\d{5}-\\d{4}$'
);
CREATE TABLE us_snail_addy (
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [PATCHES] Problem with Create Domain example
On Saturday 30 April 2005 21:14, Alvaro Herrera wrote:
On Sat, Apr 30, 2005 at 06:12:27PM -0400, Robert Treat wrote:
--- 167,174
programlisting
CREATE DOMAIN us_postal_code AS TEXT
CHECK(
!VALUE ~ '^\\d{5}$'
! OR VALUE ~ '^\\d{5}-\\d{4}$'
);
Huh, why not
VALUE ~ '^\\d{5}(-\\d{4})?$'
?
Not sure what your driving at here... my point is that the \ escaping is
incorrect in the current examples.
If you want to argue that we could make the check constraint simpler (or is
that more advanced) that seems like another issue. IMHO having the OR'd
checks is better because it shows that you can stack constraints inside a
domain if you want.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] Problem with Create Domain example
On Sunday 01 May 2005 11:58, Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
The example given in create domain seems to be broken. ISTM it requires
some extra escaping to be usable (at least in my goings on today it sure
was, and I the entries in pg_constraint sure seem to indicate this as
well). I suggest that the examples should be updated as per the
following patch.
Applied, thanks.
Is there any plans to back patch this into 8.0.x? It kind of bothers me to
think anyone trying to give domains a swing on the new database might get
stopped in thier tracks because they cant make the documentation example from
the website work. If not I'll add a comment to the site, but backpatching
seems better.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
[PATCHES] add navigation links for domains
A couple of the domain commands were missing see also references, this patch
adds those references.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Index: alter_domain.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/ref/alter_domain.sgml,v
retrieving revision 1.13
diff -c -r1.13 alter_domain.sgml
*** alter_domain.sgml 27 Nov 2004 21:27:07 - 1.13
--- alter_domain.sgml 1 May 2005 02:19:21 -
***
*** 199,205
/para
/refsect1
! refsect1
titleCompatibility/title
para
--- 199,205
/para
/refsect1
! refsect1 id=SQL-ALTERDOMAIN-compatibility
titleCompatibility/title
para
***
*** 208,213
--- 208,223
productnamePostgreSQL/productname extension.
/para
/refsect1
+
+ refsect1 id=SQL-ALTERDOMAIN-see-also
+ titleSee Also/title
+
+ simplelist type=inline
+memberxref linkend=sql-createdomain endterm=sql-createdomain-title/member
+memberxref linkend=sql-dropdomain endterm=sql-dropdomain-title/member
+ /simplelist
+ /refsect1
+
/refentry
!-- Keep this comment at the end of the file
Index: create_domain.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/ref/create_domain.sgml,v
retrieving revision 1.20
diff -c -r1.20 create_domain.sgml
*** create_domain.sgml 4 Jan 2005 00:39:53 - 1.20
--- create_domain.sgml 1 May 2005 02:19:21 -
***
*** 203,209
/refentry
-
!-- Keep this comment at the end of the file
Local variables:
mode: sgml
--- 203,208
Index: drop_domain.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/ref/drop_domain.sgml,v
retrieving revision 1.14
diff -c -r1.14 drop_domain.sgml
*** drop_domain.sgml 29 Nov 2003 19:51:38 - 1.14
--- drop_domain.sgml 1 May 2005 02:19:21 -
***
*** 93,100
--- 93,102
simplelist type=inline
memberxref linkend=sql-createdomain endterm=sql-createdomain-title/member
+memberxref linkend=sql-alterdomain endterm=sql-alterdomain-title/member
/simplelist
/refsect1
+
/refentry
!-- Keep this comment at the end of the file
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] psql backslash consistency
On Fri, 2005-05-27 at 03:45, Peter Eisentraut wrote:
Tom Lane wrote:
Greg Sabino Mullane [EMAIL PROTECTED] writes:
Attached is my backslash consistency patch which basically makes
all the backslash commands behave as \dt does: \d* shows non-system
objects, and \d*S shows system objects.
Could we have a way to turn this off? At least for functions and
operators? For my usage, at least, this will be a serious step
backwards in usefulness.
Do you have an implementation in mind? I'm having trouble coming up with
a way to do it cleanly.
I see hardly any use case for showing only user-defined functions or
types by default. I think consistency is not necessarily desirable
here.
See the archives for previous discussion and/or use cases.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [PATCHES] psql backslash consistency
On Friday 27 May 2005 15:09, Peter Eisentraut wrote:
Robert Treat wrote:
I see hardly any use case for showing only user-defined functions
or types by default. I think consistency is not necessarily
desirable here.
See the archives for previous discussion and/or use cases.
I didn't find any. Nevertheless, while there are undoubtedly some uses
for everything, making this the default behavior does not seem
acceptable.
ISTM it is more acceptable than you're willing to admit.
http://archives.postgresql.org/pgsql-hackers/2005-04/msg9.php
http://archives.postgresql.org/pgsql-hackers/2005-04/msg00102.php
http://archives.postgresql.org/pgsql-hackers/2004-09/msg00199.php
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [PATCHES] psql backslash consistency
On Friday 27 May 2005 20:45, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
On Fri, May 27, 2005 at 04:16:15PM -0400, Tom Lane wrote:
There seems to be a distinct lack of unanimity about that judgment ;-)
Well, yes, _across Postgres hackers_. But if we were to ask
pgsql-general I have a feeling we would measure more weight on one side.
Yeah, but which side ;-) ? I think the pg-general population would have
a very much higher fraction of people who have no user-defined functions
and therefore would see no value in \df not showing system functions.
Given that a good majority of the system functions aren't even documented, I
think you'd find it more likely people would sway toward not having the few
functions they have written not be totally hidden within the vast list of
system functions that a majority of people will never make use of. As a
point of reference, both pgadmin and phppgadmin default to the hide system
functions method and I haven't seen too many complaints.
If we put in a config variable, that at least lowers the stakes for the
losing side in the argument about what the default should be. Without
that, I think there will be some serious flamewars ahead...
I'm not against the idea of a config variable, but this is what, the third or
fourth go around on this? It seems rather unfair to put this burden upon the
current patch writer at this stage of the game if someone wants to code
the config option let them, put it shouldn't be a barrier to having the
current patch be applied.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] psql backslash consistency
On Saturday 28 May 2005 11:12, Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
I'm not against the idea of a config variable, but this is what, the
third or fourth go around on this? It seems rather unfair to put this
burden upon the current patch writer at this stage of the game...
The fact that objections keep being raised should suggest to you that
the idea is not uncontroversial. I think it's necessary to look for a
compromise that everyone can live with. You're really wasting your
breath to repeat the same arguments over and over and expect that
anyone's mind will change.
I haven't heard a new objection yet that was discussed the previous several go
arounds, and yet here we are adding yet another precondition...
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
[PATCHES] really minor sgml change
Found this in my cvs tree, guess I should submit it. Should give the proper
tagging for the compatability section of the alter domain page
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Index: alter_domain.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/ref/alter_domain.sgml,v
retrieving revision 1.14
diff -c -r1.14 alter_domain.sgml
*** alter_domain.sgml 2 May 2005 01:52:50 - 1.14
--- alter_domain.sgml 31 May 2005 13:11:35 -
***
*** 199,205
/para
/refsect1
! refsect1
titleCompatibility/title
para
--- 199,205
/para
/refsect1
! refsect1 id=SQL-ALTERDOMAIN-compatibility
titleCompatibility/title
para
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Re: [HACKERS] [PATCHES] Dbsize backend integration
On Monday 04 July 2005 10:11, Dave Page wrote:
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: 04 July 2005 14:54
To: Dave Page
Cc: Dawid Kuroczko; Andreas Pflug; Bruce Momjian;
PostgreSQL-patches; PostgreSQL-development
Subject: Re: [HACKERS] [PATCHES] Dbsize backend integration
Dave Page dpage@vale-housing.co.uk writes:
Aside from the fact that's a change to the API that we had
settled on,
it doesn't solve the actual problem of needing a suitable name for a
function that returns the size of a table /or/ index.
pg_relation_size()
or pg_table_size() can't be used for precisely the reason they were
rejected for that purpose in the first place.
Rejected by whom? pg_relation_size is an excellent choice for that.
Bruce didn't like it
(http://archives.postgresql.org/pgsql-hackers/2005-06/msg01410.php), and
you seemed to object as well
(http://archives.postgresql.org/pgsql-hackers/2005-06/msg01247.php)
Personally I'm beyond caring much now as the amount of time spent trying
to name these simple functions is wildly disproportionate the the effort
take to actually code them. I think we just need to agree there is no
perfect name and rely on the comments and docs to guide people. I think
the current names work OK, and Bruce and Dawid at least agree!
Actually I'd agree with Tom, pg_dbfile_size is ugly, and suggest to me I could
use a filename as an argument. ISTM that if we think that functions like
pg_database_size and pg_tablespace_size all make sense, the natural extension
would be functions called pg_index_size to tell us the size of an index,
pg_table_size to tell us the size of a table (table+toast) without it's
indexes, and some form of pg_table_plus_indexes_size for a table and its
indexes for those that feel we need both. I'm not sold we need a function
that can return either an index or table size, but if so something like
pg_object_size seems ambigious enough to work, and is future proof enough to
handle things like materialized views when and if they arise.
Just my .02 :-)
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] [PATCHES] Dbsize backend integration
On Monday 04 July 2005 13:25, Bruce Momjian wrote:
Robert Treat wrote:
Actually I'd agree with Tom, pg_dbfile_size is ugly, and suggest to me I
could use a filename as an argument. ISTM that if we think that
functions like pg_database_size and pg_tablespace_size all make sense,
the natural extension would be functions called pg_index_size to tell us
the size of an index, pg_table_size to tell us the size of a table
(table+toast) without it's indexes, and some form of
pg_table_plus_indexes_size for a table and its indexes for those that
feel we need both. I'm not sold we need a function that can return
either an index or table size, but if so something like pg_object_size
seems ambigious enough to work, and is future proof enough to handle
things like materialized views when and if they arise.
You are into the cycle we were in. We discussed pg_object size (too
vague) and pg_index_size (needs pg_toast_size too, and maybe toast
indexes; too many functions).
Yeah, I read those discussions, and think you were better off then than you
are now, which is why I went back to it somewhat.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] 5 new entries for FAQ
On Wed, 2005-08-10 at 04:04, Martijn van Oosterhout wrote:
[Sorry for the duplicate post, sent to wrong list first time]
Hi,
After going through pgsql-general a bit I figured there were a few
important questions missing from the FAQ, so I wrote some.
Comments welcome. I can write more, if people can suggest things to
write about. I was thinking something about collation and locales but
I'm sure sure I understand them myself.
I might suggest adding links to the relevant portions of the docs, for
example add a link to
http://www.postgresql.org/docs/8.0/static/sql-syntax.html#SQL-SYNTAX-IDENTIFIERS
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(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] PostgreSQL 8.0.3 Documentation - Chapter 30. The Information Schema
On Saturday 27 August 2005 08:37, Halley Pacheco de Oliveira wrote:
In 30.29. sql_implementation_info is written:
The table sql_information_info ...
I couldn't find the table sql_information_info. I think it shoud be
sql_implementation_info
good catch. I looked around for any other instances of this and didnt find
any... attached is a patch to correct this one.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Index: information_schema.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/information_schema.sgml,v
retrieving revision 1.20
diff -c -r1.20 information_schema.sgml
*** information_schema.sgml 28 Dec 2004 22:47:15 - 1.20
--- information_schema.sgml 27 Aug 2005 13:20:22 -
***
*** 3163,3169
titleliteralsql_implementation_info/literal/title
para
!The table literalsql_information_info/literal contains
information about various aspects that are left
implementation-defined by the SQL standard. This information is
primarily intended for use in the context of the ODBC interface;
--- 3163,3169
titleliteralsql_implementation_info/literal/title
para
!The table literalsql_implementation_info/literal contains
information about various aspects that are left
implementation-defined by the SQL standard. This information is
primarily intended for use in the context of the ODBC interface;
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [PATCHES] [HACKERS] Improved \df(+) in psql + backward-compatibility
On Monday 29 August 2005 00:33, Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
On a slightly related note, I've noticed that psql isn't backward
compatible.
We have never expected psql's \d commands to work against older server
versions, and two months after feature freeze isn't the time to start
making that happen.
That said, number of folks have looked at this problem and agree it would be
nice to do, they just haven't formed a consensus on how to do it. If you
have a plan for how you would want to approach this in 8.2, feel free to post
it.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
[PATCHES] small changes to autovacuum maintainance
Attached patch takes a swing at improving the autovacuum wording in
maintenance.sgml.
On a related note I was thinking to add a note in the runtime config section
for autovacuum_enabled that stats_start_collector and stats_row_level must be
on for enabled to work, would that still go in runtime.sgml ?
On a related note to that, I am wondering if it might be better to have the
postmaster issue a fatal error on startup if autovacuum is on and stats are
off, rather than the warning it does now. ISTM it is very easy to miss that
warning (since it is only sent to stderr and not stout afaict) and looking in
pg_settings there would be no indication that anything was wrong, other than
autovacuum being set to off (perhaps if it was set to 'error, stats disabled'
or some such it might be better?)
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Index: maintenance.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v
retrieving revision 1.46
diff -c -r1.46 maintenance.sgml
*** maintenance.sgml 13 Sep 2005 01:51:18 - 1.46
--- maintenance.sgml 16 Sep 2005 04:03:41 -
***
*** 180,186
rate of data modification commandVACUUM/command busy tables as
often as once every few minutes.) If you have multiple databases
in a cluster, don't forget to commandVACUUM/command each one;
! the program filenamevacuumdb/ may be helpful.
/para
para
--- 180,187
rate of data modification commandVACUUM/command busy tables as
often as once every few minutes.) If you have multiple databases
in a cluster, don't forget to commandVACUUM/command each one;
! the program xref linkend=app-vacuumdb endterm=app-vacuumdb-title
! may be helpful.
/para
para
***
*** 466,472
para
Beginning in productnamePostgreSQL /productname 8.1, there is a
separate optional server process called the firsttermautovacuum
! daemon/firstterm, whose purpose is to automate the issuance of
commandVACUUM/command and commandANALYZE /command commands.
When enabled, the autovacuum daemon runs periodically and checks for
tables that have had a large number of inserted, updated or deleted
--- 467,473
para
Beginning in productnamePostgreSQL /productname 8.1, there is a
separate optional server process called the firsttermautovacuum
! daemon/firstterm, whose purpose is to automate the execution of
commandVACUUM/command and commandANALYZE /command commands.
When enabled, the autovacuum daemon runs periodically and checks for
tables that have had a large number of inserted, updated or deleted
***
*** 521,549
para
Note that if any of the values in structnamepg_autovacuum/structname
! is set to a negative number, or if a tuple is not present at all in
structnamepg_autovacuum/structname for any particular table, the
equivalent value from filenamepostgresql.conf/filename is used.
/para
para
Besides the base threshold values and scale factors, there are three
! parameters that can be set for each table in structnamepg_autovacuum/structname:
! the vacuum cost delay
(structnamepg_autovacuum/structname.structfieldvac_cost_delay/structfield)
and the vacuum cost limit
! (structnamepg_autovacuum/structname.structfieldvac_cost_limit/structfield).
! They are used to set table-specific values for the
xref linkend=runtime-config-resource-vacuum-cost endterm=runtime-config-resource-vacuum-cost-title
feature. The above note about negative values also applies here, but
also note that if the filenamepostgresql.conf/filename variables
varnameautovacuum_vacuum_cost_limit/varname and
varnameautovacuum_vacuum_cost_delay/varname are also set to negative
! values, the varnamevacuum_cost_limit/varname and
varnamevacuum_cost_delay/varname values will be used instead.
- The other parameter, structnamepg_autovacuum/.structfieldenabled/,
- can be used to instruct the autovacuum daemon to skip any particular table
- by setting it to literalfalse/literal.
/para
/sect2
--- 522,550
para
Note that if any of the values in structnamepg_autovacuum/structname
! are set to a negative number, or if a tuple is not present at all in
structnamepg_autovacuum/structname for any particular table, the
equivalent value from filenamepostgresql.conf/filename is used.
/para
para
Besides the base threshold values and scale factors, there are three
! parameters that can be set for each table in structnamepg_autovacuum/structname.
! The first parameter, structnamepg_autovacuum/.structfieldenabled/,
! can be used to instruct the autovacuum daemon to skip any particular table
! by setting
Re: [PATCHES] default resource limits
On Saturday 24 December 2005 06:22, Peter Eisentraut wrote:
Am Samstag, 24. Dezember 2005 00:20 schrieb Andrew Dunstan:
The rationale is one connection per apache thread (which on Windows
defaults to 400). If people think this is too many I could live with
winding it back a bit - the defaults number of apache workers on Unix is
250, IIRC.
It's 150. I don't mind increasing the current 100 to 150, although I find
tying this to apache pretty bogus.
I really don't like the prospect of making the defaults platform specific,
especially if the only rationale for that would be apache does it. Why
does apache allocate more connections on Windows anyway?
Maybe we should write something in to check if apache is installed if we're so
concerned about that usage... I already know that I set the connection limits
lower on most of the installations I do (given than most installations are
not production webservers). There is also the argument to be made that just
because systems these days have more memory doesn't mean we have to use it.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [PATCHES] [HACKERS] Patch Submission Guidelines
On Tuesday 14 February 2006 20:42, Robert Treat wrote:
On Tuesday 14 February 2006 16:00, Martijn van Oosterhout wrote:
I would like to suggest that we increase substantially the FAQ entries
relating to patch submission. By we, I actually mean please could the
committers sit down and agree some clarified written guidelines?
As I remember, there is a disinclination to increase the size of the
FAQ very much. This suggests maintaining it as a seperate document. Or
alternatively attach it as an appendix to the main documentation.
Huh? The current developers FAQ is at least 1/2 the size of the main FAQ.
I think adding a submission on patch submission guidelines is a great idea.
I'll have a patch based on Simon's post to -patches ready in the next 24
hours unless someone is really going to object.
As stated, the following patch adds a list of patch submission guidelines
based on Simon Riggs suggestions to the developers FAQ.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Index: doc/src/FAQ/FAQ_DEV.html
===
RCS file: /projects/cvsroot/pgsql/doc/src/FAQ/FAQ_DEV.html,v
retrieving revision 1.107
diff -c -r1.107 FAQ_DEV.html
*** doc/src/FAQ/FAQ_DEV.html 24 Dec 2005 19:29:38 - 1.107
--- doc/src/FAQ/FAQ_DEV.html 16 Feb 2006 04:44:57 -
***
*** 156,180
H3 id=item1.51.5) I've developed a patch, what next?/H3
! PGenerate the patch in contextual diff format. If you are
! unfamiliar with this, you might find the script
! Isrc/tools/makediff/difforig/I useful. Unified diffs are
! only preferrable if the file changes are single-line changes and
! do not rely on the surrounding lines./P
!
! PEnsure that your patch is generated against the most recent
! version of the code. If it is a patch adding new functionality, the
! most recent version is CVS HEAD; if it is a bug fix, this will be
! the most recently version of the branch which suffers from the bug
! (for more on branches in PostgreSQL, see A href=
! #1.151.15/A)./P
!
! PFinally, submit the patch to [EMAIL PROTECTED] It
will be reviewed by other contributors to the project and will be
! either accepted or sent back for further work. Also, please try to
! include documentation changes as part of the patch. If you can't do
! that, let us know and we will manually update the documentation when
! the patch is applied./P
H3 id=item1.61.6) Where can I learn more about the
code?/H3
--- 156,226
H3 id=item1.51.5) I've developed a patch, what next?/H3
! PYou will need to submit the patch to [EMAIL PROTECTED] It
will be reviewed by other contributors to the project and will be
! either accepted or sent back for further work. To help ensure your patch
! is reviewed and committed in a timely fasion, please make sure your
! submission conforms to the following guidelines before sending your email:
! ol
! liHas patch been discussed previously? If it has, give a direct link
! to the message and/or bug# from the mail archives
! (a href=http://archives.postgresql.org/;http://archives.postgresql.org//a).
! If it has not and the patch is of any complexity it is strongly
! recommended you post a message to the appropriate list or you risk
! getting your patch rejected. Refer back to a href=#1.41.4/a for
! email guidelines./li
!
! liEnsure that your patch is generated against the most recent version
! of the code. If you are developing new features, this should be
! CVS HEAD; if it is a bug fix, this will be the most recent version of
! the branch which suffers from the bug. For more on branches in
! PostgreSQL, see a href=#1.151.15/a./li
!
! liThe patch should be generated in contextual diff format and should
! be applicable from the root directory. If you are unfamiliar with
! this, you might find the script Isrc/tools/makediff/difforig/I
! useful. Unified diffs are only preferrable if the file changes are
! single-line changes and do not rely on the surrounding lines./li
!
! liPostgreSQL is licensed under a BSD license, so any submissions must
! conform to the BSD license to be included. If you use code that is
! available under some other license that is BSD compatible (eg. public
! domain) please note that code in your email submission/li
!
! liConfirm that your changes can pass make check and list the
! platforms you have tested this on. If your changes are port specific,
! list the ports that it applies to./li
!
! liProvide an implementation overview, preferably in code comments./li
!
! liIf it is a performance patch, provide confirming test results to
! show the benefits of your patch. It is OK to post patches without
! this information, though the patch will not be applied until *somebody*
! has tested
Re: [PATCHES] [HACKERS] Patch Submission Guidelines
On Thursday 16 February 2006 00:27, Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
! liThe patch should be generated in contextual diff format and
should !be applicable from the root directory. If you are
unfamiliar
with ! this, you might find the script
Isrc/tools/makediff/difforig/I !useful. Unified diffs
are only
preferrable if the file changes are ! single-line changes and
do not
rely on the surrounding lines./li
I'd like the policy to be contextual diffs are preferred, full stop.
Unidiffs are more compact but they sacrifice readability of the patch
(IMHO anyway) and when you are preparing a patch you should be thinking
first in terms of making it readable for the reviewers/committers.
Some things that follow along with the readability mandate, and should
be brought out somewhere here:
* avoid unnecessary whitespace changes. They just distract the
reviewer, and your formatting changes will probably not survive
the next pgindent run anyway.
would diff -c --ignore-space-change be better?
* try to follow the project's code-layout conventions; again, this
makes it easier for the reviewer, and there's no long-term point
in trying to do it differently than pgindent would.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [PATCHES] [HACKERS] Patch Submission Guidelines
On Thursday 16 February 2006 00:27, Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
As stated, the following patch adds a list of patch submission guidelines
based on Simon Riggs suggestions to the developers FAQ.
A couple minor comments ...
Attached patch updated based on previous feedback.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Index: doc/src/FAQ/FAQ_DEV.html
===
RCS file: /projects/cvsroot/pgsql/doc/src/FAQ/FAQ_DEV.html,v
retrieving revision 1.107
diff -c -r1.107 FAQ_DEV.html
*** doc/src/FAQ/FAQ_DEV.html 24 Dec 2005 19:29:38 - 1.107
--- doc/src/FAQ/FAQ_DEV.html 16 Feb 2006 20:08:51 -
***
*** 156,180
H3 id=item1.51.5) I've developed a patch, what next?/H3
! PGenerate the patch in contextual diff format. If you are
! unfamiliar with this, you might find the script
! Isrc/tools/makediff/difforig/I useful. Unified diffs are
! only preferrable if the file changes are single-line changes and
! do not rely on the surrounding lines./P
!
! PEnsure that your patch is generated against the most recent
! version of the code. If it is a patch adding new functionality, the
! most recent version is CVS HEAD; if it is a bug fix, this will be
! the most recently version of the branch which suffers from the bug
! (for more on branches in PostgreSQL, see A href=
! #1.151.15/A)./P
!
! PFinally, submit the patch to [EMAIL PROTECTED] It
will be reviewed by other contributors to the project and will be
! either accepted or sent back for further work. Also, please try to
! include documentation changes as part of the patch. If you can't do
! that, let us know and we will manually update the documentation when
! the patch is applied./P
H3 id=item1.61.6) Where can I learn more about the
code?/H3
--- 156,231
H3 id=item1.51.5) I've developed a patch, what next?/H3
! PYou will need to submit the patch to [EMAIL PROTECTED] It
will be reviewed by other contributors to the project and will be
! either accepted or sent back for further work. To help ensure your patch
! is reviewed and committed in a timely fasion, please try to make sure your
! submission conforms to the following guidelines:
! ol
! liHas the patch been discussed previously? If it has, give a direct link
! to the message and/or bug# from the mail archives
! (a href=http://archives.postgresql.org/;http://archives.postgresql.org//a).
! If it has not and the patch is of any complexity it is strongly
! recommended you post a message to the appropriate list or you risk
! getting your patch rejected. Refer back to a href=#1.41.4/a for
! email guidelines./li
!
! liEnsure that your patch is generated against the most recent version
! of the code, which for developers is CVS HEAD. For more on branches in
! PostgreSQL, see a href=#1.151.15/a./li
!
! liTry to make your patch as readable as possible. Try to follow the
! project's code-layout conventions; again, this makes it easier for the
! reviewer, and there's no long-term point in trying to do it
! differently than pgindent would. Also avoid unnecessary whitespace
! changes, they just distract the reviewer, and your formatting changes
! will probably not survive the next pgindent run anyway./li
!
! liThe patch should be generated in contextual diff format and should
! be applicable from the root directory. If you are unfamiliar with
! this, you might find the script Isrc/tools/makediff/difforig/I
! useful./li
!
! liPostgreSQL is licensed under a BSD license, so any submissions must
! conform to the BSD license to be included. If you use code that is
! available under some other license that is BSD compatible (eg. public
! domain) please note that code in your email submission/li
!
! liConfirm that your changes can pass make check and list the
! platforms you have tested this on. If your changes are port specific,
! list the ports that it applies to./li
!
! liProvide an implementation overview, preferably in code comments./li
!
! liIf it is a performance patch, provide confirming test results to
! show the benefits of your patch. It is OK to post patches without
! this information, though the patch will not be applied until *somebody*
! has tested the patches and found a valuable performance effect directly
! attributable to the patch. Given that writing performance tests is not
! terribly exciting, it is recommended you take this task upon yourself./li
!
! liIf it is a new feature patch, confirm that it has been tested for
! all desired scenarios. If it has not, this should be clearly stated as
! a request for a particular kind of test to be performed. Note that the
! patch will go no further until that test has been performed./li
Re: [PATCHES] [HACKERS] please actualize FAQ, broken urls
On Friday 07 April 2006 16:10, Pavel Stehule wrote:
Hello
1.11) How can I learn SQL?
...
There is also a nice tutorial at
http://www.intermedia.net/support/sql/sqltut.shtm, at
http://ourworld.compuserve.com/homepages/graeme_birchall/HTM_COOK.HTM, and
at http://sqlcourse.com.
first link is broken, second moved
thanks for the report, the attached patch updates that section.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Index: FAQ.html
===
RCS file: /projects/cvsroot/pgsql/doc/src/FAQ/FAQ.html,v
retrieving revision 1.336
diff -c -r1.336 FAQ.html
*** FAQ.html 3 Apr 2006 03:40:20 - 1.336
--- FAQ.html 8 Apr 2006 02:33:14 -
***
*** 355,367
Bowman, Judith S., et al., Addison-Wesley. Others like IThe
Complete Reference SQL/I, Groff et al., McGraw-Hill./P
! PThere is also a nice tutorial at A href=
! http://www.intermedia.net/support/sql/sqltut.shtm;http://www.intermedia.net/support/sql/sqltut.shtm,/A
! at A href=
! http://ourworld.compuserve.com/homepages/graeme_birchall/HTM_COOK.HTM;
! http://ourworld.compuserve.com/homepages/graeme_birchall/HTM_COOK.HTM,/A
! and at A href=
! http://sqlcourse.com/;http://sqlcourse.com./A/P
H3 id=item1.121.12) How do I join the development
team?/H3
--- 355,365
Bowman, Judith S., et al., Addison-Wesley. Others like IThe
Complete Reference SQL/I, Groff et al., McGraw-Hill./P
! PThere are also many nice tutorials available online, including the ones
! at A HREF=http://sqlcourse.com/;http://sqlcourse.com//A,
! A HREF=http://www.w3schools.com/sql/default.asp;
! http://www.w3schools.com/sql/default.asp/A, and A
! href=http://mysite.verizon.net/Graeme_Birchall/id1.html;http://mysite.verizon.net/Graeme_Birchall/id1.html/A./P
H3 id=item1.121.12) How do I join the development
team?/H3
---(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] Update link for GUI Tools in FAQ
Attached patch updates FAQ 2.3 updating the link for the GUI Tools page to the
new page in the new techdocs, along with some verbage changes. Note this
link should be updated by all translators.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Index: FAQ.html
===
RCS file: /projects/cvsroot/pgsql/doc/src/FAQ/FAQ.html,v
retrieving revision 1.345
diff -c -r1.345 FAQ.html
*** FAQ.html 23 May 2006 15:51:07 - 1.345
--- FAQ.html 31 May 2006 14:22:40 -
***
*** 471,479
H3 id=item2.32.3) Does PostgreSQL have a graphical user
interface?/H3
! PYes, see a href=http://techdocs.postgresql.org/guides/GUITools;
! http://techdocs.postgresql.org/guides/GUITools/a for a
! detailed list./P
HR
--- 471,480
H3 id=item2.32.3) Does PostgreSQL have a graphical user
interface?/H3
! PThere are a large number of GUI Tools that are available for PostgreSQL
! from both commercial and open source developers. A detailed list can be
! found in the A href=http://www.postgresql.org/docs/techdocs.54;
! PostgreSQL Community Documentation/A/P
HR
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [PATCHES] [PATCH] Magic block for modules
On Wednesday 31 May 2006 13:24, Martijn van Oosterhout wrote:
On Wed, May 31, 2006 at 11:14:27AM -0400, Tom Lane wrote:
Is it worth adding a module name to the magic block, or should we just
leave well enough alone? It's certainly not something foreseen as part
of the purpose of that block. In the absence of some fairly concrete
ideas what to do with it, I'm probably going to vote keep-it-simple.
I actually considered it while writing the patch but decided against
given the general tendancy against putting extra info into the modules
in general...
Personally I think it's a good idea, except: where is this info going
to be displayed or used?
Marko's suggestion on producing a list of installed modules comes to mind, and
I suspect tools like pgadmin or ppa will want to be able to show this
information.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(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] [PATCH] Magic block for modules
On Thursday 01 June 2006 21:38, Christopher Kings-Lynne wrote:
Marko's suggestion on producing a list of installed modules comes to
mind, and I suspect tools like pgadmin or ppa will want to be able to
show this information.
My request for phpPgAdmin is to somehow be able to check if the .so file
for a module is present.
For instance, I'd like to 'enable slony support' if the slony shared
library is present. PPA's slony support automatically executes the .sql
files, so all I need to know is if the .so is there.
While I agree with the above (having that for tsearch2 would be nice too) I
think we ought to keep in mind the idea of sql based modules. Nothing jumps
to mind here ppa wise, but I could see an application looking to see if
mysqlcompat was installed before running if it had a good way to do so.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] drop if exists remainder
On Saturday 04 March 2006 22:24, David Fetter wrote:
On Fri, Mar 03, 2006 at 03:35:24PM -0500, Andrew Dunstan wrote:
Bruce Momjian wrote:
Christopher Kings-Lynne wrote:
What's the consensus on this? Nobody else has chimed in, so I'm inclined
to do no more on the gounds of insufficient demand. Let's decide before
too much bitrot occurs, though.
+1 :)
+1
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
[PATCHES] update link / fix spelling error
Updates the link for the sql 2003 spec, also fixes a spelling error.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Index: FAQ_DEV.html
===
RCS file: /projects/cvsroot/pgsql/doc/src/FAQ/FAQ_DEV.html,v
retrieving revision 1.109
diff -c -r1.109 FAQ_DEV.html
*** FAQ_DEV.html 1 Mar 2006 22:24:51 - 1.109
--- FAQ_DEV.html 7 Jun 2006 21:19:29 -
***
*** 199,205
#1.161.16/a./li
liIf you are adding a new feature, confirm that it has been tested
! thoughly. Try to test the feature in all conceivable
scenarios./li
liIf it is a performance patch, please provide confirming test
--- 199,205
#1.161.16/a./li
liIf you are adding a new feature, confirm that it has been tested
! thoroughly. Try to test the feature in all conceivable
scenarios./li
liIf it is a performance patch, please provide confirming test
***
*** 704,710
http://www.cse.iitb.ac.in/dbms/Data/Papers-Other/SQL1999/ansi-iso-9075-2-1999.pdf/A/LI
LISQL:2003 A href=
! http://www.wiscorp.com/sql/sql_2003_standard.zip;http://www.wiscorp.com/sql/sql_2003_standard.zip/A/LI
/UL
PSome SQL standards web pages are:/P
--- 704,710
http://www.cse.iitb.ac.in/dbms/Data/Papers-Other/SQL1999/ansi-iso-9075-2-1999.pdf/A/LI
LISQL:2003 A href=
! http://www.wiscorp.com/sql_2003_standard.zip;http://www.wiscorp.com/sql_2003_standard.zip/A/LI
/UL
PSome SQL standards web pages are:/P
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
[PATCHES] update commercial services link
Updates link to support companies from old techdocs to main website
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Index: doc/src/FAQ/FAQ.html
===
RCS file: /projects/cvsroot/pgsql/doc/src/FAQ/FAQ.html,v
retrieving revision 1.349
diff -c -r1.349 FAQ.html
*** doc/src/FAQ/FAQ.html 18 Jun 2006 19:33:31 - 1.349
--- doc/src/FAQ/FAQ.html 30 Jun 2006 19:05:14 -
***
*** 240,247
(I#postgresqlfr/I). There is also a PostgreSQL channel on EFNet./P
PA list of commercial support companies is available at A href=
! http://techdocs.postgresql.org/companies.php;
! http://techdocs.postgresql.org/companies.php/A./P
H3 id=item1.81.8) How do I submit a bug report?/H3
--- 240,247
(I#postgresqlfr/I). There is also a PostgreSQL channel on EFNet./P
PA list of commercial support companies is available at A href=
! http://www.postgresql.org/support/professional_support;
! http://www.postgresql.org/support/professional_support/A./P
H3 id=item1.81.8) How do I submit a bug report?/H3
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [PATCHES] [DOCS] maintenance diff
On Thursday 13 July 2006 20:58, Joshua D. Drake wrote:
Hello,
Updated to have stronger wording for vacuuming. Cleaned out some extra
superlatives. Added a couple of index entries for Routine Maintenance
and added entry specific to Analyze.
I noticed a number of typos in this...
s/Gbord/Gborg/
s/Gforg/Gforge/
s/including, mailing/including mailing
s/forums and cvs/forums, and cvs,/
s/pgFoundry/PgFoundry/
I think there might be some other issues too... like saying gborg is
deprecated is likely to imply something wrong with the projects there rather
than the site itself.
There were a couple of other minor things I noticed too... Joshua, do you mind
if I make some changes and resubmit this patch?
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [PATCHES] [DOCS] Maintenance and External Projects (try 2)
On Friday 14 July 2006 15:23, Joshua D. Drake wrote:
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Please let me know if there is anything else you would like me to do or
add.
A round of copy-editing seems indicated, at least.
Oh, no doubt. I tried to fix as much as I find, including a bunch of
stuff already there. However, I do not claim, in any way to be an editor.
The following patches provide some editorializing for Joshua's patches.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
Index: doc/src/sgml/external-projects.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/external-projects.sgml,v
retrieving revision 1.10
diff -c -r1.10 external-projects.sgml
*** doc/src/sgml/external-projects.sgml 10 Mar 2006 19:10:47 - 1.10
--- doc/src/sgml/external-projects.sgml 15 Jul 2006 02:22:02 -
***
*** 1,29
!-- $PostgreSQL: pgsql/doc/src/sgml/external-projects.sgml,v 1.10 2006/03/10 19:10:47 momjian Exp $ --
appendix id=external-projects
! titleExternal Projects/title
para
productnamePostgreSQL/productname is a complex software project,
!and managing it is difficult. We have found that many
enhancements to productnamePostgreSQL/productname can be more
!efficiently developed separately from the core project. Separate
!projects can
!have their own developer teams, email lists, bug tracking,
!and release schedules. While their independence makes
!development easier, it makes users' jobs harder. They have to hunt
!around looking for database enhancements to meet their needs.
!This section describes some of the more popular externally
!developed enhancements and guides you on how to find them.
/para
para
!Many productnamePostgreSQL/productname-related projects are
!hosted at either
!ulink url=http://gborg.postgresql.org;productnameGBorg//ulink
!or ulink url=http://pgfoundry.org;productnamepgFoundry//ulink.
!There are other productnamePostgreSQL/productname-related projects that are hosted
!elsewhere, but you will have to do an Internet search to find them.
/para
sect1 id=external-interfaces
--- 1,34
!-- $PostgreSQL: pgsql/doc/src/sgml/external-projects.sgml,v 1.10 2006/03/10 19:10:47 momjian Exp $ --
appendix id=external-projects
! titlePgFoundry and External Projects/title
para
productnamePostgreSQL/productname is a complex software project,
!and managing the project is difficult. We have found that many
enhancements to productnamePostgreSQL/productname can be more
!efficiently developed separately from the core project.
! /para
!
! para
!To help our community with the development of their external projects,
!we have created the ulink url=http://www.pgfoundry.org/;PgFoundry/ulink.
!ulink url=http://www.pgfoundry.org/;PgFoundry/ulink is built using the
!GForge software project and is similar to SourceForge in its feature set. If
!you have a PostgreSQL related Open Source project that you would like to
!develop and need project management resources such as mailing lists, forums,
!bug tracking, and CVS, please feel free to create a new project.
/para
para
!Secondly, many productnamePostgreSQL/productname-related projects are
!still hosted at ulink url=http://gborg.postgresql.org;productnameGBorg//ulink.
!GBorg is the original external community developer site, and while it is
!currently closed to new projects in favor of PgFoundry, it still contains
!many active and relevant projects. There are other popular productnamePostgreSQL/productname
!related projects that are hosted independently as well at other community
!sites such as ulink url=http://www.sf.net;SourceForge/ulink. You should
!google if you don't find the project you are looking for.
/para
sect1 id=external-interfaces
***
*** 36,46
para
productnamePostgreSQL/productname includes very few interfaces
with the base distribution. applicationlibpq/ is packaged because
!it is the primary applicationC/ interface and many other
!interfaces are built on top of it. applicationecpg/ is packaged
!because it is tied to the server-side grammar so is very dependent
!on the database version. All the other interfaces are independent
!projects and must be installed separately.
/para
para
--- 41,50
para
productnamePostgreSQL/productname includes very few interfaces
with the base distribution. applicationlibpq/ is packaged because
!it is the primary dependecy of most interfaces available to PostgreSQL.
!We also package applicationecpg/ because it is tied to the
!server-side grammar. All other interfaces, such as PHP, Perl, Python,
!and Ruby, are external projects.
/para
para
Re: [PATCHES] Mark change-on-restart-only values in postgresql.conf
On Tuesday 18 July 2006 17:44, Zdenek Kotala wrote:
I added additional comments marked setting which need server restart to
take effect. I use (!RSR!) tag for it, however if anybody have different
idea, let me know and I will change it.
Out of curisoity, does the !RSR! actually have some meaning? !RRS (requires
restart) or !RR or !RS (restart) all seem more straightforward.
More importantly, I think you need to mark all of the variables with the
special tag individually, as opposed to where, like in the kerberos settings,
you just say all kerberose settings require restart. This is mainly
because...
I removed comments about commenting out behavior too, because patch now
waiting for commit (or reject?).
I know some setups remove all commented options from the postgresql.conf, so
that only modified parameters are left inside the postgresql.conf. If they
want to change a setting, they add it into the conf. I think the theory is
that this is either more secure, since it would require more knowledge to
modify the postgres settings this way, or it is a nod to making
postgresql.conf more portable accross versions (by keeping a smaller subset
of changes its more likely they will work across versions) or in an effort to
make the postgresql.conf simpler (by removing a lot of variables that will
never be modified)... in any case it is a valid setup in 8.1, unfortunatly I
haven't had time to test your patch with CVS, but do you know if it can
support those types of configurations?
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(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] extension for sql update
On Thursday 27 July 2006 09:28, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
UPDATE mytab SET (foo, bar, baz) =
(SELECT alpha, beta, gamma FROM othertab WHERE key = mytab.key);
That UPDATE example is interesting because I remember when using
Informix that I had to do a separate SELECT statement for each UPDATE
column I wanted to update. I didn't realize that you could group
columns and assign them from a single select --- clearly that is a
powerful syntax we should support some day.
No question. The decision at hand is whether we want to look like
we support it, when we don't yet. I'd vote not, because I think the
main use-case for the row-on-the-left syntax is exactly this, and
so I fear people will just get frustrated if they see it in the
syntax synopsis and try to use it.
I'm not a big fan of implementing partial solutions (remember left-joins are
not implemented messages :-) way back when) , however in my experience with
this form of the update command, the primary usage is not to use a subselect
to derive the values, but to make it easier to generate sql, using a single
update statement, based on an array of passed in values (in languages like
perl/php/etc...). This solution would solve that problem for us, so I would
lean toward including it. I would be interested in hearing from actual users
who really need the subselect version though, but right now my thinking is
that group is a small minority of who would benefit from this version of the
update command.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] [PATCHES] COPY view
On Tuesday 22 August 2006 16:10, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
It sucks that patches are posted and no action is taken on them for
months. I agree with that.
This particular patch was originally posted during the 8.1 feature
freeze window (2005-09-29), so it was doomed to a certain amount of
languishing on the to-worry-about-later list in any case. We should
have gotten around to reviewing it sooner than we did (the followup
discussion was around 2006-06-14), but there was still plenty of time
at that point to rework it per the discussion and get it into 8.2.
As I see it, we've effectively got a patch that was rejected once,
and Bruce wants to apply it anyway because no replacement has been
forthcoming.
Well, unless someone is going to commit to doing it the other way, it seems
the guy who actually codes something offers a better solution than
handwaving... people have also had plenty of time to come up with a
replacement if that's what they really wanted.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
[PATCHES] minor editorial of tsearch2 readme
just fixes up a couple of minor points,
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
Index: README.tsearch2
===
RCS file: /projects/cvsroot/pgsql/contrib/tsearch2/README.tsearch2,v
retrieving revision 1.3
diff -c -r1.3 README.tsearch2
*** README.tsearch2 4 Aug 2004 21:33:37 - 1.3
--- README.tsearch2 26 Sep 2006 00:50:51 -
***
*** 5,12
This module is sponsored by Delta-Soft Ltd., Moscow, Russia.
Notice: This version is fully incompatible with old tsearch (V1),
!which is considered as deprecated in upcoming 7.4 release and
!obsoleted in 8.0.
The Tsearch2 contrib module contains an implementation of a new data
type tsvector - a searchable data type with indexed access. In a
--- 5,11
This module is sponsored by Delta-Soft Ltd., Moscow, Russia.
Notice: This version is fully incompatible with old tsearch (V1),
!which was deprecated in 7.4 and obsoleted in 8.0.
The Tsearch2 contrib module contains an implementation of a new data
type tsvector - a searchable data type with indexed access. In a
***
*** 56,62
* Brandon Craig Rhodes wrote Tsearch2 Guide and Tsearch2
Reference and proposed new naming convention for tsearch V2
! New features
* Relevance ranking of search results
* Table driven configuration
--- 55,61
* Brandon Craig Rhodes wrote Tsearch2 Guide and Tsearch2
Reference and proposed new naming convention for tsearch V2
! Features Added with Tsearch2
* Relevance ranking of search results
* Table driven configuration
---(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
On Tuesday 26 December 2006 23:12, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Alvaro Herrera wrote:
I'm not really convinced that Bruce's proposed names seem any better
to me. What's wrong with dead and live?
In my mind, visible really means visible to anyone, and expired means
visible to no one.
Um ... surely, visibility is in the eye of the beholder (no smiley).
I don't have an immediate suggestion for better terminology, but IMHO
the whole point of visible/invisible terminology is that it depends on
who's looking. Dead and live seem to convey a more appropriate air
of finality.
Expired is OK as a synonym for dead, but there is no thesaurus
anywhere in the world that will suggest it as an antonym for visible.
OK, so we need new terminology and we need it to be used consistenly in
our documentation, whatever we choose.
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.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(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
On Saturday 06 January 2007 16:40, Bruce Momjian wrote:
Simon Riggs wrote:
Or in other words, does this patch mean that all COPY execution that
is within a transaction will ignore WAL?
Yes, because it is possible to do in all cases.
Very happy to add documentation where Tom suggested.
Reason for no documentation was that CREATE INDEX and CREATE TABLE AS
SELECT already use this optimisation, but to my knowledge neither was/is
documented on those command pages.
I wasn't aware those used the optimization. Seems they all should be
documented somewhere.
Might I suggest somewhere under chapter 27, with something akin to what we
have for documenting lock levels and the different operations that use them.
We document the reasons you want to avoid WAL and various operations in the
database that do this automagically.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(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
On Saturday 06 January 2007 16:36, Simon Riggs wrote:
The rule is: if the relfilenode for a table is new in this transaction
(and therefore the whole things will be dropped at end-of-transaction)
then *all* COPY commands are able to avoid writing WAL safely, if:
- PITR is not enabled
- there is no active portal (which could have been opened on an earlier
commandid and could therefore see data prior to the switch to the new
relfilenode). In those cases, *not* using WAL causes no problems at all,
so sleep well without it.
snip
BEGIN;
CREATE TABLE foo...
INSERT INTO foo --uses WAL
COPY foo.. --no WAL
INSERT INTO foo --uses WAL
COPY foo.. --no WAL
INSERT INTO foo --uses WAL
COPY foo... --no WAL
COMMIT;
Is there some technical reason that the INSERT statements need to use WAL in
these scenarios? ISTM that in the above scenario there are no cases where
the INSERT statements are any more recoverable than the COPY statements.
While there might not be much gain from bypassing WAL on a single insert, in
bunches, or more importantly when doing INSERT INTO foo SELECT *, it could be
a nice improvement as well. Am I overlooking something?
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(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: [pgsql-patches] [PATCHES] Tablespace for temporary objects and
On Sunday 14 January 2007 23:16, Jaime Casanova wrote:
On 1/13/07, Albert Cervera Areny [EMAIL PROTECTED] wrote:
It was already possible to set the guc on postgresql.conf when I posted
the patch...
ok... fixed... the problem was that this code only let
num_temp_tablespaces be greater than zero when we are in an
interactive command (eg. a SET command) but setting the guc from
postgresql.conf at startup time is not interactive so
num_temp_tablespaces is zero and when i try to get the first temp
tablespace to use (MyProcPid % num_temp_tablespaces) causes a floatin
exception (division by zero).
snip
new patch added, with that piece of code refactored to let
num_temp_tablespaces get a value greater than zero always that the guc
is setted, i also add some docs.
the patch passes all 104 regression tests and all my tests as well...
i think the patch is ready to be applied to HEAD, any committer want
to review it?
Why is this PGC_SUSET? ISTM it should be PGC_USERSET.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(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] Fwd: Re: [DOCS] [HACKERS] Broken link in PG docs
Can someone apply Jim's patch at least to HEAD and REL8_2_STABLE? We recently
got a report of a broken link on the website due to this; seems it is still
broken...
-- Forwarded Message --
Subject: Re: [DOCS] [HACKERS] Broken link in PG docs
Date: Monday 25 September 2006 15:39
From: Jim C. Nasby [EMAIL PROTECTED]
To: Gurjeet Singh [EMAIL PROTECTED]
Cc: pgsql-docs@postgresql.org
Moving to -docs
On Mon, Sep 25, 2006 at 04:44:47PM +0530, Gurjeet Singh wrote:
At the end of the following page:
http://www.postgresql.org/docs/8.0/static/indexes-partial.html
there is a link [Generalized Partial
Indexeshttp://simon.cs.cornell.edu/home/praveen/papers/partindex.de95.ps.Z
] which is pointing to a missing link.
Can someone update the link with a live doc? Probably
this one
http://citeseer.ist.psu.edu/rd/0%252C67014%252C1%252C0.25%252CDownload/htt
p://citeseer.ist.psu.edu/cache/papers/cs/1722/http:zSzzSzsimon.cs.cornell.ed
uzSzhomezSzpraveenzSzpaperszSzpartindex.de95.pdf/seshadri95generalized.pdf
Hrm... is there any means to update the docs for older versions outside
of a new release?
Even if the answer is 'no', it'd still be good to make the change in
CVS. See attached (btw, this is in the docs back to at least 7.2).
--
Jim Nasby[EMAIL PROTECTED]
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
---
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
Index: doc/src/sgml/biblio.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/biblio.sgml,v
retrieving revision 1.25
diff -c -r1.25 biblio.sgml
*** doc/src/sgml/biblio.sgml16 Sep 2006 00:30:11 - 1.25
--- doc/src/sgml/biblio.sgml25 Sep 2006 19:38:00 -
***
*** 326,332
biblioentry id=SESHADRI95
biblioset relation=article
! titleulink
url=http://simon.cs.cornell.edu/home/praveen/papers/partindex.de95.ps.Z;
Generalized Partial Indexes
/ulink
/title
--- 326,332
biblioentry id=SESHADRI95
biblioset relation=article
! titleulink
url=http://citeseer.ist.psu.edu/rd/0%252C67014%252C1%252C0.25%252CDownload/http://citeseer.ist.psu.edu/cache/papers/cs/1722/http:zSzzSzsimon.cs.cornell.eduzSzhomezSzpraveenzSzpaperszSzpartindex.de95.pdf/seshadri95generalized.pdf;
Generalized Partial Indexes
/ulink
/title
---(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] Fwd: Re: [DOCS] [HACKERS] Broken link in PG docs
On Wednesday 07 February 2007 23:35, Bruce Momjian wrote:
Robert Treat wrote:
Can someone apply Jim's patch at least to HEAD and REL8_2_STABLE? We
recently got a report of a broken link on the website due to this; seems
it is still broken...
OK, we were aware that the URL was bad, but were trying to avoid
pointing to the cached version. You will see that comment in the old
SGML.
What I did was to point to the Citeseer page, but not into the cached
PDF. I think the text saying cached version will make it clear people
have to click to see the paper, and we aren't deep linking into
Citeseer, which I think could be a problem, and the cached URL is one of
the longest I have ever seen.
As an alternative, if we could get a copy of the paper and permission from the
authors, we could host it on postgresql.org.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [pgsql-patches] [PATCHES] pg_standby
At the risk of starting trouble, is there some reason this was added to
contrib and not put on pgfoundry ?
On Thursday 08 February 2007 10:09, Bruce Momjian wrote:
Patch applied. Thanks.
---
Simon Riggs wrote:
On Wed, 2007-01-17 at 16:15 +, Simon Riggs wrote:
On Wed, 2007-01-17 at 10:05 -0500, Merlin Moncure wrote:
On 12/28/06, Simon Riggs [EMAIL PROTECTED] wrote:
On Thu, 2006-12-28 at 19:26 +, Simon Riggs wrote:
On Thu, 2006-12-14 at 12:04 +, Simon Riggs wrote:
pg_standby and test framework, in separate .tar files
New version (v2), following further testing.
Signal handling not included in this version.
Signal handling now added, tested and working correctly in version
3, attached.
pg_standby is an example program for a warm standby script as
discussed on -hackers:
http://archives.postgresql.org/pgsql-hackers/2006-08/msg00407.php
Program looks complete and ready for review, to me.
I double checked and re-ran all my test and confirmed that pg_standby
move (-m) mode is definitely busted in v3 in the sense that a restart
of the standby will not resume recovery and requires a pg_resetxlog
to become operational -- it needs one more WAL file back than the
oldest one available.
new v4
Changes
- removed -m command, design flaw in original spec, use -l instead
- added -k N command to cleanup archive and leave max N files
- fflush() points added to allow Windows debug
- bug fix: when .history file present
- bug fix: command line switch cleanup
- readme updated
new v6 (v5 was Windows dev release)
Changes
- added -r option to specify maxretries
- -l option for Windows Vista (only) using mklink
- Windows examples and docs added to readme
- code restructured to allow more easy customization
- bug fix: -k 0 error fixed
- successful port report from Dave Page on Windows XP
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
[ Attachment, skipping... ]
---(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
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 6: explain analyze is your friend
[PATCHES] FAQ_DEV Update: Fix Answer for Q 1.19, add Q on SCMS
Subject pretty much says it all. Somewhere the answer to 1.19 got regurgitated to 2.9, so this corrects that and adds an answer to the SCMS question based on recent hackers thread. -- Robert Treat Database Architect OmniTI Computer Consulting, Inc. -- http://www.omniti.com/ Index: FAQ_DEV.html === RCS file: /projects/cvsroot/pgsql/doc/src/FAQ/FAQ_DEV.html,v retrieving revision 1.126 diff -c -r1.126 FAQ_DEV.html *** FAQ_DEV.html 19 Feb 2007 23:45:38 - 1.126 --- FAQ_DEV.html 26 Feb 2007 21:01:36 - *** *** 57,62 --- 57,64 site development?BR A href=#item1.191.19/A) What is the timeline for the next major PostgreSQL release?BR + A href=#item1.201.20/A) Why haven't you replaced CVS with SVN, Git, + Monotone, VSS, lt;insert your favorite SCM system heregt;? H2Technical Questions/H2 *** *** 708,714 the source code is available at A href= http://gborg.postgresql.org/project/pgweb/projdisplay.php;http://gborg.postgresql.org/project/pgweb/projdisplay.php/A , the code for the next version of the website is under the ! portal module. H2Technical Questions/H2 --- 710,751 the source code is available at A href= http://gborg.postgresql.org/project/pgweb/projdisplay.php;http://gborg.postgresql.org/project/pgweb/projdisplay.php/A , the code for the next version of the website is under the ! portal module./P ! ! H3 id=item1.191.19) What is the timeline for the next major ! PostgreSQL release?/H3 ! ! PThe development schedule for the 8.3 release is:/P ! DL ! DDMarch 1, 2007/DD ! DTInitial community review of all major feature patches/DT ! DDApril 1, 2007/DD ! DTFeature freeze, all patches must be submitted for review and application/DT ! DDmid-May, 2007/DD ! DTAll patches applied, beta testing begins/DT ! DDJuly, 2007/DD ! DTRelease of 8.3.0/DT ! /DL ! ! PPatches that appear after appropriate dates are typically ! not applied but held for the next major release./P ! ! H3 id=item1.201.20) Why haven't you replaced CVS with SVN, Git, ! Monotone, VSS, lt;insert your favorite SCMS heregt;?/H3 ! ! PCurrently the core developers see no SCMS that will provide ! enough benefit to outwiegh the pain involved in moving to a new ! SCMS. Typical problems that must be addressed by any new SCMS include:/P ! ul ! liRun natively on all of our a href=http://www.postgresql.org/docs/current/interactive/supported-platforms.html;supported platforms/a./li ! liIntegrate into the a href=http://pgbuildfarm.org/;Buildfarm/a./li ! liImport our entire CVS Repository while preserving complete history./li ! liAllow for anonymous checkouts./li ! /ul ! PCurrently there is no intention for switching to a new SCMS until at least the ! end of the 8.4 development cycle sometime in late 2008. For more information ! please refer to the mailing list archives./P ! H2Technical Questions/H2 *** *** 998,1021 requires a compile with I-DLINUX_PROFILE/I for proper profiling./P - H3 id=item2.92.9) What is the timeline for the next major - PostgreSQL release?BR - - PThe development schedule for the 8.3 release is:/P - DL - DDMarch 1, 2007/DD - DTInitial community review of all major feature patches/DT - DDApril 1, 2007/DD - DTFeature freeze, all patches must be submitted for review and application/DT - DDmid-May, 2007/DD - DTAll patches applied, beta testing begins/DT - DDJuly, 2007/DD - DTRelease of 8.3.0/DT - /DL - - PPatches that appear after appropriate dates are typically - not applied but held for the next major release./P - /BODY /HTML --- 1035,1040 ---(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] Have vacuum emit a warning when it runs out of maintenance_work_mem
On Wednesday 09 May 2007 19:41, Guillaume Smet wrote:
On 5/9/07, Tom Lane [EMAIL PROTECTED] wrote:
Jim Nasby [EMAIL PROTECTED] writes:
Any time this happens it's generally a nasty surprise for users.
Really? Running out of work memory is expected on large tables.
Sure. Perhaps we should find a better error message but it's an
interesting information. Personnaly, I try to choose a sane value
depending on my database but I'm never sure it's really sufficient or
if I added 100MB it would have made a real difference.
If we were going to implement this (and I'm a tad skeptical as well), wouldn't
it be better if the warning occured at the end of vacuum, and told you how
much memory was actually needed, so you'd know what maintainence_work_mem
should be.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(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] [pgsql-www] out of date url in developer faq
Forwarding to -patches. FWIW I looked around a little and couldn't find a
suitable replacement, but if someone knows of one (or can find one) we could
replace the link rather than remove it.
On Friday 15 June 2007 20:23, David Gardner wrote:
I was just reading the pgsql developer faq :
http://www.postgresql.org/docs/faqs.FAQ_DEV.html
and noticed that question 1.11 refers to an out of date url
http://www.benchmarkresources.com/
diff
*** faqs.FAQ_DEV.html-orig Fri Jun 15 17:20:16 2007
--- faqs.FAQ_DEV.html Fri Jun 15 17:21:05 2007
***
*** 512,520
and iTransaction Processing,/i by Jim Gray, Morgan,
Kaufmann/p
- pThere is also a database performance site, with a handbook
- on-line written by Jim Gray at a
href=http://www.benchmarkresources.com/;http://www.benchmarkresources.com
./a./p -
h3 id=item1.121.12) What is configure all about?/h3
pThe files iconfigure/i and iconfigure.in/i are part of
--- 512,517
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
[PATCHES] dblink connection security
Patch based on recent -hackers discussions, it removes usage from public, and
adds a note to the documentation about why this is neccessary.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
Index: contrib/dblink/dblink.sql.in
===
RCS file: /projects/cvsroot/pgsql/contrib/dblink/dblink.sql.in,v
retrieving revision 1.11
diff -c -r1.11 dblink.sql.in
*** contrib/dblink/dblink.sql.in 2 Sep 2006 21:11:15 - 1.11
--- contrib/dblink/dblink.sql.in 1 Jul 2007 15:34:20 -
***
*** 8,13
--- 8,18
AS 'MODULE_PATHNAME','dblink_connect'
LANGUAGE C STRICT;
+ -- Comment these lines to give access to dblink to all users.
+ -- Please read security note in doc/connection before doing so.
+ REVOKE * ON dblink_connect(text) FROM PUBLIC;
+ REVOKE * ON dblink_connect(text,text) FROM PUBLIC;
+
CREATE OR REPLACE FUNCTION dblink_disconnect ()
RETURNS text
AS 'MODULE_PATHNAME','dblink_disconnect'
Index: contrib/dblink/doc/connection
===
RCS file: /projects/cvsroot/pgsql/contrib/dblink/doc/connection,v
retrieving revision 1.4
diff -c -r1.4 connection
*** contrib/dblink/doc/connection 11 Mar 2006 04:38:29 - 1.4
--- contrib/dblink/doc/connection 1 Jul 2007 15:34:20 -
***
*** 61,66
--- 61,75
Returns status = OK
+ Note
+
+ As a security precaution, dblink revokes access from PUBLIC role usage for
+ the dblink_connect functions. One example attack method is that of
+ remote users using dblink to gain access to accounts that may not
+ require re-authentication from local connections (which dblink provides).
+ Other possible attack vectors are explored in a paper on PostgreSQL security
+ at http://www.leidecker.info/pgshell/Having_Fun_With_PostgreSQL.txt.
+
Example usage
test=# select dblink_disconnect();
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [PATCHES] dblink connection security
On Sunday 01 July 2007 13:15, Gregory Stark wrote:
Joe Conway [EMAIL PROTECTED] writes:
Robert Treat wrote:
Patch based on recent -hackers discussions, it removes usage from
public, and adds a note to the documentation about why this is
neccessary.
I agree with the fix as the simplest and most sensible approach, and in
general with the doc change, but I'm not inclined to reference the
security paper. Maybe something like:
As a security precaution, dblink revokes access from PUBLIC role
usage for the dblink_connect functions. It is not safe to allow
remote users to execute dblink from a database in a PostgreSQL
installation that allows local account access using the trust
authentication method. In that case, remote users could gain
access to other accounts via dblink. If trust authentication
is disabled, this is no longer an issue.
I think putting the emphasis on Postgresql trust authentication is missing
the broader point. I would suggest two paragraphs such as:
dblink allows any connected user to attempt to connect to TCP/IP or Unix
sockets from the database server as the user the database system is
running. This could allow users to circumvent access control policies based
on the connecting user or the connecting host.
In particular Postgres's trust authentication is one such system. It
authenticates connecting users based on the unix userid of the process
forming the connection. In typical configurations any user who is granted
execute access to dblink can form connections as the postgres user which
is the database super-user. If trust authentication is disabled this is
no longer an issue.
Did you mean s/trust/ident/g, otherwise I don't think I understand the
above... granted the combination of trust for localhost does open a door
for remote users if they have access to dblink, but I don't think that's what
you were trying to say.
Therefore dblink requires you to explicitly grant execute privileges to
users or roles you wish to allow to form connections. It does not grant
these privileges to the PUBLIC role by default as other packages typically
do.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
Re: [PATCHES] dblink connection security
On Sunday 01 July 2007 16:03, Joe Conway wrote:
Tom Lane wrote:
Joe Conway [EMAIL PROTECTED] writes:
Tom Lane wrote:
Would it be sensible to change dblink so that unless invoked by a
superuser, it fails any connection attempt in which no password is
demanded? I am not sure that this is possible without changes to
libpq; but ignoring implementation difficulties, is this a sane idea
from the standpoint of security and usability?
Possibly so. Remember that dblink is simply a libpq client. Doesn't that
mean that similar (although likely less severe) issues affect other
libpq clients executing locally, such as php or perl-dbi clients?
Yeah, in principle this issue applies to any process performing a
Postgres connection on behalf of someone else. (Whether there are any
programs doing that, other than dblink, is debatable; but someday there
may be.)
Well certainly dbi-link has the exact same issue.
dbi-link only works in plperlu, so you've already decided your superuser only.
And a local php-apache
instance connecting to Postgres would allow Postgres connections as the
apache user, no? Not that it is likely to be a problem, but if for some
reason there was an apache user in Postgres, and even worse, if that
user was given superuser status, you would have the exact same problem.
That doesnt seem like the same problem to me, since those connections are
still from an external source. The issue with dblink is that because you are
making a connection from a postgres process, you are connecting as the
postgres user when you weren't that user before.
The point about Kerberos delegation is interesting, but given that it
doesn't work anyway, I'm not sure we need a solution for it right now.
Possibly, when and if we get around to implementing it, we can somehow
treat use of a delegated ticket as equivalent to use of a password.
The general point is that we'd like to know whether the connection was
authorized by means of some data supplied by the client, or on the basis
of our own process identity (the latter being the case we wish to
reject). Right now the only kind of data supplied by the client here
is a password.
Here's a straw-man proposal that we could perhaps do for 8.3:
1. Invent a libpq connection-status function
bool PQconnectionUsedPassword(const PGconn *conn);
Maybe PQconnectionUsedAuthToken() to mean data supplied by the client,
including other potential future mechanisms?
2. Make dblink close the connection and throw error if called by a
non-superuser and PQconnectionUsedPassword returns false.
Sounds good to me.
This idea isn't usable as a back-patch, however, because adding
functions to existing libpq versions is too chancy. What we could
possibly do in back versions is, if dblink_connect is called by a
non-superuser, first issue the connection attempt without any password
and reject if that doesn't fail. (This'd involve parsing the connect
string well enough to remove the password, which is tedious, but
certainly doable.)
Why not just require the connect string to contain a password for
non-superusers?
I like this approach better than removing public execute privileges
on the functions, for two reasons:
* A routine minor version update would install the security fix into
existing installations, without need for any DBA intervention.
* It does not take away functionality that has perfectly legitimate uses.
Agreed.
I think this will break backwards compatability though. ie. non-superusers
may be calling functions that are relying on dblink to connect sans password,
which would be broken by the above changes. I'm pretty sure it can be worked
around (though the work around is ugly, you cant hardcode passwords in the
functions or else people can look them up in pgproc) but people may need to
make changes to thier code to live with this.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] dblink connection security
On Sunday 01 July 2007 17:59, Joe Conway wrote:
Joe Conway wrote:
Robert Treat wrote:
Joe Conway [EMAIL PROTECTED] writes:
Well certainly dbi-link has the exact same issue.
dbi-link only works in plperlu, so you've already decided your superuser
only.
How so -- it is fundamentally no different than dblink, which is C
language (also untrusted).
I think the issue is that once the superuser creates said functions,
usage of the functions is automatically granted to PUBLIC, no? Being an
untrusted language just means that it takes a superuser to create the
functions using that language, not to use the functions themselves.
In fact, this misconception can prove dangerous in other ways. From the
docs:
CREATE FUNCTION badfunc() RETURNS integer AS $$
my $tmpfile = /tmp/badfile;
open my $fh, '', $tmpfile
or elog(ERROR, qq{could not open the file $tmpfile: $!});
print $fh Testing writing to a file\n;
close $fh or elog(ERROR, qq{could not close the file $tmpfile: $!});
return 1;
$$ LANGUAGE plperlu;
select usename, usesuper from pg_shadow;
usename | usesuper
--+--
postgres | t
foo | f
(2 rows)
contrib_regression=# \c - foo
You are now connected to database contrib_regression as user foo.
contrib_regression= select badfunc();
badfunc
-
1
(1 row)
So anyone thinking that just because a language is untrusted means that
they don't need to be careful, is mistaken.
lol... you're absolutly correct, I wasn't thinking clearly earlier. I took a
3-hour nap shortly after my last email, I probably should have taken it
before :-)
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(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] Lazy xid assignment V4
On Wednesday 05 September 2007 12:56, Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
However, none of these are very strong reasons - certainly weaker than
doing what ensures to cause the least confusion. I'm therefore
starting to think that we should remove transaction, and keep the name
virtualtransaction for the VXID. That will ensure that clients who
*do* rely on pg_locks and the transaction column (which will be few,
I guess) at least fail early and visibly, instead of producing bogus
results...
Reading the docs, it says Every transaction holds an exclusive lock on its
virtual transaction ID for its entire duration. If a permanent ID is assigned
to the transaction (which normally happens only if the transaction changes
the state of the database), it also holds an exclusive lock on its permanent
transaction ID until it ends.
ISTM that by removing the transaction column, there is no way to see the XID
for relations thats have been updated (which by definition will have locks on
them). Am I mis-reading the docs, or have we lost that functionality?
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Expose checkpoint start/finish times into SQL.
On Thursday 03 April 2008 19:08, Andrew Dunstan wrote:
Joshua D. Drake 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.
Even if this were true, surely the answer is to improve the logging.
Exposing everything into the log files isn't always sufficient (says the guy
who maintains a remote admin tool)
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
--
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.
On Thursday 03 April 2008 21:14, Joshua D. Drake wrote:
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.
You can plug a single item graphed over time into things like rrdtool to get
good trending information. And it's often easier to do this using sql
interfaces to get the data than pulling it out of log files (almost like the
db was designed for that :-)
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.
Knowing when the last checkpoint occured is certainly useful for monitoring
purposes (wrt pitr and as a general item for cuasing alerts if checkpoints
stop occuring frequently enough, or if they start taking too long.)
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.
How does one measure when the bgwriter is failing at this effort?
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
--
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.
On Friday 04 April 2008 00:09, Greg Smith wrote:
On Thu, 3 Apr 2008, Robert Treat wrote:
You can plug a single item graphed over time into things like rrdtool to
get good trending information. And it's often easier to do this using
sql interfaces to get the data than pulling it out of log files (almost
like the db was designed for that :-)
The pg_stat_bgwriter value for buffers_checkpoint was intentionally
implemented in 8.3 such that it jumps in one big lump when the checkpoint
is done. While it's not the ideal interface for what you're looking for,
the reason for that is to made it possible to build a when was the last
checkpoint finished? interface via some remote monitoring tool just by
determining the last time that the value jumped upwards. You can easily
see them just by graphing that value, it shouldn't be too hard to teach
something with rrdtool guts to find them.
the advantage of using a timestamp is that you get the incrementing counter
for free which is certainly helpful in third party tools like phppgadmin that
don't instrument tracking methods; you can look at the system and it's
settings and have a pretty good idea if something is awry.
Ultimately a lot of the other questions you might ask (i.e. how many
buffers have been written per hour by checkpoints?) require processing
the numbers in this way anyway, and I thought this implementation was good
enough to monitor the situation you're trying to avoid--presuming you're
using some sort of moderately powerful remote monitoring tool. Theo's
patch would make it easier to answer with a simple command which has some
value; a little SQL in a cron job would be good enough to trigger an alert
rather than needing a real monitoring probe.
Yes, the idea of making a basic nagios/munin check that is readily consumable
by the general public is certainly a bonus in my eyes.
I have to add, given that we already provide the time of last checkpoint
information via pg_controldata, I don't understand why people are against
making that information accesible to remote clients.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
--
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.
On Friday 04 April 2008 01:59, Tom Lane wrote:
Greg Smith [EMAIL PROTECTED] writes:
On Thu, 3 Apr 2008, Tom Lane wrote:
I'd much rather be spending our time and effort on understanding what
broke for you, and fixing the code so it doesn't happen again.
[ shit happens... ]
Completely fair, but I still don't see how this particular patch would
be a useful addition to the DBA's monitoring-tool arsenal. The scope
seems too narrow.
So, thinking about this for a few minutes, here are some of the things that
knowing the last checkpoint time might help a DBA determine.
1) Alert if checkpointing stops occuring within a reasonable time frame (note
there are failure cases and normal use cases where this might occur) (also
note I'll agree, this isn't common, but the results are pretty disatrous if
it does happen)
2) Can be graphed over time (using rrdtool and others) for trending checkpoint
activity
3) Ease monitoring of checkpoints across pitr setups
4) Help determine if your checkpoints are being timeout driven or segment
driven, or if you need to look at those settings
5) Determine the number of log files that will need to be replayed in the
event of a crash
6) Helps give an indication on if you should enter a manual checkpoint before
issuing a pg_start_backup call
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
--
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] Extending grant insert on tables to sequences
On Saturday 24 May 2008 01:19:05 Jaime Casanova wrote:
On Sat, May 24, 2008 at 12:09 AM, Alvaro Herrera
[EMAIL PROTECTED] wrote:
Please add the patch to the commitfest page,
Ah! I forgot we have a new process now... patch added to the commitfest
page...
What's the use case for extending SELECT on table to SELECT on sequence ?
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
